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é d'une certaine plateforme de relais pour voler 20 millions de dollars. Dans les jours suivants, les développeurs ont publié 5 correctifs pour résoudre ce problème, mais combiné avec la latence du réseau existant et les stratégies des validateurs, cela a entraîné une brève instabilité du réseau Ethereum le 6 avril. La restructuration est nuisible à la santé du réseau, car elle réduit le taux de production de blocs et diminue les garanties de règlement.
Cet article vise à explorer l'interaction entre certains protocoles et consensus, à révéler les subtilités du mécanisme d'attestation d'Ethereum, et à énumérer quelques pistes possibles pour l'avenir. Nous avons été inspirés par les attaques subies par les chercheurs et les événements d'instabilité temporaire du réseau.
L'importance d'un certain protocole
Un protocole conçu par la communauté vise à atténuer l'impact négatif de la valeur extratable maximale (MEV) sur le réseau Ethereum.
Il y a trois rôles dans ce protocole :
Relai - Connecte le proposeur aux enchérisseurs fiables des constructeurs de blocs.
Constructeurs - Construire des blocs pour maximiser la complexité de soi-même et de l'entité MEV du proposant.
Proposeur - validateur d'attestation Ethereum.
La séquence des événements pour chaque bloc est la suivante : le constructeur crée le bloc et le soumet au relais ; le relais vérifie la validité du bloc et calcule les frais à payer au proposant ; le relais envoie l'en-tête de "signature aveugle" et la valeur de paiement au proposant du créneau horaire actuel ; le proposant évalue toutes les offres reçues et signe l'en-tête de la signature aveugle liée au paiement le plus élevé ; le proposant renvoie l'en-tête signé au relais ; le relais utilise le nœud de balise local pour publier le bloc et le renvoyer au proposant.
Ce protocole est une infrastructure clé, car 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 choix de fork d'Ethereum et un certain protocole
Avant d'entrer dans les attaques et les réponses approfondies, examinons d'abord le mécanisme de attestation d'Ethereum ( PoS ) et les règles de sélection de fork qui y sont associées. Les règles de sélection de fork permettent au réseau de parvenir à un consensus sur la tête de chaîne.
La règle de sélection des forks est une fonction évaluée par le client, qui prend en entrée les blocs et messages vus et produit la "chaîne officielle". La nécessité d'une règle de sélection des forks est due au fait qu'il peut exister plusieurs chaînes valides parmi lesquelles choisir.
Un aspect peu connu des règles de sélection des forks est leur relation avec le temps, ce qui a un impact majeur sur le mining.
cycles de slot et de sous-slot
Dans le PoS d'Ethereum, le temps est divisé en créneaux de 12 secondes. L'algorithme PoS désigne aléatoirement un validateur pour proposer un bloc dans ce créneau ; ce validateur est appelé proposeur. Dans le même créneau, d'autres validateurs sont assignés pour voter en soutien au dernier bloc situé à l'emplacement de la tête de chaîne dans leur vue locale, en appliquant des règles de sélection de fork. L'intervalle de 12 secondes est divisé en trois phases, chacune durant 4 secondes.
Le moment clé 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 pour le chef de chaîne précédent. Plus un bloc est proposé tôt, plus il a de temps pour se propager et accumuler plus de témoins.
D'un point de vue de la santé du réseau, le meilleur temps de bloc est t=0. Cependant, puisque la valeur du bloc augmente avec le temps, le proposeur a l'incitation à retarder la publication pour accumuler plus de MEV.
Historiquement, même après la période d'attestation et même près de la fin du créneau, les proposeurs pouvaient encore publier des blocs tant que le prochain validateur les observait avant de construire le bloc du créneau suivant. Pour encourager un comportement rationnel ( le retard de publication ) vers un comportement honnête ( la publication à temps ) a été mise en œuvre "restructuration honnête".
Amélioration et réorganisation honnête du proposeur
Deux nouveaux concepts ont été introduits dans le client de consensus, ayant un impact clé sur la date limite d'attestation :
Amélioration du proposeur - Minimiser l'attaque de réorganisation d'équilibre en accordant au proposeur le choix de "l'élévation" équivalant à 40 % du poids d'attestation complet. Cette amélioration ne dure qu'un seul créneau horaire.
Reconstruction honnête - Utiliser l'amélioration des proposeurs et permettre aux proposeurs honnêtes de l'utiliser pour forcer la réorganisation des blocs ayant moins de 20 % de poids d'attestation. Cela est implémenté dans certains clients. Ce changement est optionnel, car il s'agit d'une décision locale du proposeur et n'affecte pas le comportement des validateurs.
Éviter de procéder à une restructuration honnête dans certaines situations particulières :
Pendant la période des blocs de frontière d'époque
Si la chaîne n'est pas terminée
Si le bloc de tête n'est pas obtenu à partir de la tranche temporelle avant le bloc de réorganisation
La condition 3 garantit 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 à produire des blocs pendant des délais de réseau extrêmes. Cela reflète également la diminution de la confiance du proposeur dans sa vue du réseau.
Correction des relais et des nœuds de balise contre les attaques de désengagement
Lors de l'attaque du 2 avril, le proposeur a exploité une vulnérabilité de relais en envoyant des en-têtes de signature invalides. Les jours suivants, l'équipe de développement du relais et du noyau a publié plusieurs correctifs pour réduire le risque d'attaques répétées. Les principaux changements sont les suivants:
Changement de relais:
Vérifiez si la base de données contient des proposeurs 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 avant de publier le bloc
Le changement de nœud de la chaîne de balises ( ne s'applique qu'aux nœuds de balises de relais ) :
Vérifier la validité du bloc de balise de diffusion avant
Vérifiez s'il existe des équivalents sur le réseau avant de publier le bloc.
Ces changements ont entraîné une instabilité du consensus, et la plupart des validateurs utilisent maintenant une stratégie de réorganisation honnête, ce qui aggrave encore cette situation.
conséquences imprévues
Chacune des 5 modifications ci-dessus a augmenté le délai sur le chemin chaud de publication des blocs relais, augmentant ainsi la probabilité que les blocs relais dépassent la date limite d'attestation.
Avant d'effectuer ces vérifications, le temps d'arrivée de l'en-tête de signature est nettement plus tardif que t=0(, tandis que t=3) ne pose généralement pas de problème. Les frais de relais sont très faibles, donc le bloc sera publié avant t=4.
Cependant, avec l'augmentation des retards introduits par le patch, le relais peut maintenant provoquer un retard de diffusion. Dans certains cas, l'envoi tardif des en-têtes signés par le proposeur, combiné à des retards supplémentaires introduits par le relais, entraîne le non-respect de la date limite d'attestation. En l'absence de réorganisation honnête, ces blocs entreront très probablement dans la chaîne. Mais en cas de réorganisation honnête, le non-respect de la date limite d'attestation signifie que ce bloc sera réorganisé par le prochain proposeur.
Ainsi, dans les jours qui ont suivi l'attaque, le nombre de blocs forkés a considérablement augmenté. Dans le pire des cas, 13 blocs ( ont été réorganisés en une heure, soit environ 4,3 %) de plus que la normale. Avec le déploiement de diverses modifications par le relais, l'augmentation soudaine 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 sain.
Les changements les plus utiles actuellement sont la vérification d'équivalence avant la validation et la diffusion des blocs de 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.
direction future
Dans ce contexte, la communauté de recherche devrait évaluer ce qui est un nombre de réorganisations "acceptable" et considérer les risques associés aux attaques équivalentes pour déterminer si des mesures d'atténuation sont nécessaires.
Actuellement, nous explorons activement plusieurs directions futures :
Mettre en œuvre "headlock" pour prévenir les attaques équivalentes
Augmenter le programme de primes pour les vulnérabilités des logiciels concernés
Étendre le logiciel de simulation pour étudier l'impact du minutage des sous-fenêtres sur la stabilité du réseau
Optimiser le chemin de publication des blocs sur le relais pour réduire la latence
Intégrer un certain protocole dans le client de consensus
Ajouter plus de tests basés sur les problèmes de délai et de date limite d'attestation
Encourager la diversité des clients relais
Envisager d'ajuster les mesures de pénalité équivalentes
Dans l'ensemble, nous sommes enthousiasmés par l'énergie renouvelée autour de l'MEV et de l'écosystème connexe. Grâce à cet événement, nous avons compris la relation clé entre les délais, certains protocoles et les mécanismes de consensus ; nous espérons que le protocole pourra continuer à se renforcer.
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.
20 J'aime
Récompense
20
6
Reposter
Partager
Commentaire
0/400
NFTFreezer
· 08-17 04:05
eth a été attaqué par un Hacker, et alors ?
Voir l'originalRépondre0
MevHunter
· 08-17 03:03
Ça commence à être casse-tête, n'est-ce pas ?
Voir l'originalRépondre0
Deconstructionist
· 08-14 17:13
J'en peux plus, ce mécanisme de POS est trop compliqué.
Voir l'originalRépondre0
GasWaster
· 08-14 17:08
je viens de dépenser 5 eth dans des tx échoués... le pos n'est plus sûr smh
Voir l'originalRépondre0
Degen4Breakfast
· 08-14 16:58
Encore une journée dans l'univers de la cryptomonnaie.
Voir l'originalRépondre0
TheMemefather
· 08-14 16:49
C'est déjà 20 millions de dollars, c'est vraiment intéressant.
Analyse du mécanisme de consensus PoS d'Ethereum : temps, créneaux et tri des événements
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é d'une certaine plateforme de relais pour voler 20 millions de dollars. Dans les jours suivants, les développeurs ont publié 5 correctifs pour résoudre ce problème, mais combiné avec la latence du réseau existant et les stratégies des validateurs, cela a entraîné une brève instabilité du réseau Ethereum le 6 avril. La restructuration est nuisible à la santé du réseau, car elle réduit le taux de production de blocs et diminue les garanties de règlement.
Cet article vise à explorer l'interaction entre certains protocoles et consensus, à révéler les subtilités du mécanisme d'attestation d'Ethereum, et à énumérer quelques pistes possibles pour l'avenir. Nous avons été inspirés par les attaques subies par les chercheurs et les événements d'instabilité temporaire du réseau.
L'importance d'un certain protocole
Un protocole conçu par la communauté vise à atténuer l'impact négatif de la valeur extratable maximale (MEV) sur le réseau Ethereum.
Il y a trois rôles dans ce protocole :
La séquence des événements pour chaque bloc est la suivante : le constructeur crée le bloc et le soumet au relais ; le relais vérifie la validité du bloc et calcule les frais à payer au proposant ; le relais envoie l'en-tête de "signature aveugle" et la valeur de paiement au proposant du créneau horaire actuel ; le proposant évalue toutes les offres reçues et signe l'en-tête de la signature aveugle liée au paiement le plus élevé ; le proposant renvoie l'en-tête signé au relais ; le relais utilise le nœud de balise local pour publier le bloc et le renvoyer au proposant.
Ce protocole est une infrastructure clé, car 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 choix de fork d'Ethereum et un certain protocole
Avant d'entrer dans les attaques et les réponses approfondies, examinons d'abord le mécanisme de attestation d'Ethereum ( PoS ) et les règles de sélection de fork qui y sont associées. Les règles de sélection de fork permettent au réseau de parvenir à un consensus sur la tête de chaîne.
La règle de sélection des forks est une fonction évaluée par le client, qui prend en entrée les blocs et messages vus et produit la "chaîne officielle". La nécessité d'une règle de sélection des forks est due au fait qu'il peut exister plusieurs chaînes valides parmi lesquelles choisir.
Un aspect peu connu des règles de sélection des forks est leur relation avec le temps, ce qui a un impact majeur sur le mining.
cycles de slot et de sous-slot
Dans le PoS d'Ethereum, le temps est divisé en créneaux de 12 secondes. L'algorithme PoS désigne aléatoirement un validateur pour proposer un bloc dans ce créneau ; ce validateur est appelé proposeur. Dans le même créneau, d'autres validateurs sont assignés pour voter en soutien au dernier bloc situé à l'emplacement de la tête de chaîne dans leur vue locale, en appliquant des règles de sélection de fork. L'intervalle de 12 secondes est divisé en trois phases, chacune durant 4 secondes.
Le moment clé 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 pour le chef de chaîne précédent. Plus un bloc est proposé tôt, plus il a de temps pour se propager et accumuler plus de témoins.
D'un point de vue de la santé du réseau, le meilleur temps de bloc est t=0. Cependant, puisque la valeur du bloc augmente avec le temps, le proposeur a l'incitation à retarder la publication pour accumuler plus de MEV.
Historiquement, même après la période d'attestation et même près de la fin du créneau, les proposeurs pouvaient encore publier des blocs tant que le prochain validateur les observait avant de construire le bloc du créneau suivant. Pour encourager un comportement rationnel ( le retard de publication ) vers un comportement honnête ( la publication à temps ) a été mise en œuvre "restructuration honnête".
Amélioration et réorganisation honnête du proposeur
Deux nouveaux concepts ont été introduits dans le client de consensus, ayant un impact clé sur la date limite d'attestation :
Amélioration du proposeur - Minimiser l'attaque de réorganisation d'équilibre en accordant au proposeur le choix de "l'élévation" équivalant à 40 % du poids d'attestation complet. Cette amélioration ne dure qu'un seul créneau horaire.
Reconstruction honnête - Utiliser l'amélioration des proposeurs et permettre aux proposeurs honnêtes de l'utiliser pour forcer la réorganisation des blocs ayant moins de 20 % de poids d'attestation. Cela est implémenté dans certains clients. Ce changement est optionnel, car il s'agit d'une décision locale du proposeur et n'affecte pas le comportement des validateurs.
Éviter de procéder à une restructuration honnête dans certaines situations particulières :
La condition 3 garantit 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 à produire des blocs pendant des délais de réseau extrêmes. Cela reflète également la diminution de la confiance du proposeur dans sa vue du réseau.
Correction des relais et des nœuds de balise contre les attaques de désengagement
Lors de l'attaque du 2 avril, le proposeur a exploité une vulnérabilité de relais en envoyant des en-têtes de signature invalides. Les jours suivants, l'équipe de développement du relais et du noyau a publié plusieurs correctifs pour réduire le risque d'attaques répétées. Les principaux changements sont les suivants:
Ces changements ont entraîné une instabilité du consensus, et la plupart des validateurs utilisent maintenant une stratégie de réorganisation honnête, ce qui aggrave encore cette situation.
conséquences imprévues
Chacune des 5 modifications ci-dessus a augmenté le délai sur le chemin chaud de publication des blocs relais, augmentant ainsi la probabilité que les blocs relais dépassent la date limite d'attestation.
Avant d'effectuer ces vérifications, le temps d'arrivée de l'en-tête de signature est nettement plus tardif que t=0(, tandis que t=3) ne pose généralement pas de problème. Les frais de relais sont très faibles, donc le bloc sera publié avant t=4.
Cependant, avec l'augmentation des retards introduits par le patch, le relais peut maintenant provoquer un retard de diffusion. Dans certains cas, l'envoi tardif des en-têtes signés par le proposeur, combiné à des retards supplémentaires introduits par le relais, entraîne le non-respect de la date limite d'attestation. En l'absence de réorganisation honnête, ces blocs entreront très probablement dans la chaîne. Mais en cas de réorganisation honnête, le non-respect de la date limite d'attestation signifie que ce bloc sera réorganisé par le prochain proposeur.
Ainsi, dans les jours qui ont suivi l'attaque, le nombre de blocs forkés a considérablement augmenté. Dans le pire des cas, 13 blocs ( ont été réorganisés en une heure, soit environ 4,3 %) de plus que la normale. Avec le déploiement de diverses modifications par le relais, l'augmentation soudaine 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 sain.
Les changements les plus utiles actuellement sont la vérification d'équivalence avant la validation et la diffusion des blocs de 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.
direction future
Dans ce contexte, la communauté de recherche devrait évaluer ce qui est un nombre de réorganisations "acceptable" et considérer les risques associés aux attaques équivalentes pour déterminer si des mesures d'atténuation sont nécessaires.
Actuellement, nous explorons activement plusieurs directions futures :
Dans l'ensemble, nous sommes enthousiasmés par l'énergie renouvelée autour de l'MEV et de l'écosystème connexe. Grâce à cet événement, nous avons compris la relation clé entre les délais, certains protocoles et les mécanismes de consensus ; nous espérons que le protocole pourra continuer à se renforcer.