Des chercheurs du développeur de clients Ethereum Nethermind ont publié un benchmark examinant jusqu'à quelle taille le budget de validation défini par le paramètre MAX_VERIFY_GAS de l'EIP-8141 peut croître avant que les nœuds Ethereum ne soient exposés à des attaques par déni de service (DoS) sur le mempool. La conclusion centrale de l'étude est qu'une protection au niveau du client — la suspension de la validation du mempool pendant le traitement d'un bloc — fait la différence entre une limite de 300 000 gaz viable et une configuration qui épuise les ressources des nœuds sous un flot adversaire soutenu.

Ce que le budget de validation de l'EIP-8141 est conçu pour contraindre

L'EIP-8141 est une proposition Core Standards Track en statut Draft intitulée « Frame Transaction ». Selon son objectif déclaré, la proposition ajoute une couche d'abstraction de frame pour la validation des transactions, l'exécution et le paiement du gaz, permettant aux transactions de transporter une logique de validation personnalisée avant d'être admises dans le mempool puis éventuellement incluses dans un bloc. Le texte de la proposition est disponible sur le dépôt EIP d'Ethereum. Le mempool lui-même est la file d'attente où les nœuds conservent les transactions ayant passé la validation en attendant leur inclusion dans un bloc, ce qui fait du calcul à l'étape d'admission le point central de la préoccupation DoS abordée ici.

Le budget de validation — défini par un paramètre appelé MAX_VERIFY_GAS — fixe le volume de calcul qu'un nœud doit effectuer pour admettre une seule transaction frame. À 100 000 gaz par transaction, la limite actuelle du projet est trop basse pour accommoder des cas d'usage réels : une dépense de confidentialité Groth16 à note unique nécessite 211 828 gaz pour la validation, et les variantes de signatures SPHINCS+ exigent jusqu'à 276 000 gaz. La limite doit donc augmenter pour être pratique, mais chaque révision à la hausse élargit la surface d'attaque disponible pour les adversaires disposés à inonder les nœuds de transactions coûteuses échouant à la validation.

Cette tension de conception est familière à quiconque a suivi le débat sur l'abstraction de compte de l'EIP-4337 : le travail de validation qui se produit hors du chemin d'exécution est peu coûteux à déclencher pour les attaquants mais coûteux à absorber pour les nœuds. L'EIP-8141 déplace ce travail dans un budget imposé par le protocole, ce qui rend au moins le coût borné. L'emplacement de cette borne implique toutefois un arbitrage direct entre richesse fonctionnelle et résilience du mempool.

L'EIP-8141 reste une proposition en draft et n'est activée sur aucun réseau Ethereum en production. Les résultats du benchmark constituent un apport de recherche à cette discussion de conception, et non la description d'une configuration déployée.

Comment le benchmark mesure l'exposition au DoS du mempool

Les chercheurs de Nethermind ont inondé un nœud Nethermind à un seul cœur de transactions échouant à la validation, sur trois machines aux performances variées, en testant des limites MAX_VERIFY_GAS allant de 100 000 à 500 000 gaz. La métrique principale était de savoir si la surcharge de validation maintient la latence d'importation des blocs dans un budget de 25 ms — le seuil en dessous duquel le traitement normal des blocs est considéré comme non affecté par la charge de travail concurrente du mempool. Le compte rendu complet figure sur le forum Ethereum Research.

Sans protection côté client, les résultats étaient contraignants. Sur le profil de nœud complet le plus lent, le nœud n'est resté dans le budget de délai d'importation de 25 ms que jusqu'à environ 15 millions de gaz de validation par seconde. À un taux de flot de 100 transactions échouant à la validation par seconde, ce plafond de débit ne laissait que la limite de 100 000 gaz dans le budget — ce qui signifie que toute augmentation de la limite permettant une validation cryptographique réelle créerait aussi un vecteur de DoS viable sur le matériel typique des opérateurs de nœuds domestiques.

Le benchmark évalue deux axes distincts de la santé du mempool : la sécurité du traitement des blocs (la surcharge de validation retarde-t-elle l'importation des blocs ?) et l'équité d'admission des transactions (les émetteurs honnêtes parviennent-ils toujours à faire admettre leurs transactions frame dans le mempool lorsqu'un adversaire inonde le réseau ?). Ces deux axes n'évoluent pas ensemble, raison pour laquelle le mécanisme de protection ne résout pas l'intégralité du problème même lorsqu'il traite bien le premier axe.

Le mécanisme de protection et son coût résiduel

La protection proposée au sein du client est simple : suspendre la validation du mempool pendant que le nœud traite un bloc entrant. Cela découple les deux charges de travail en concurrence pour le même cœur de CPU, empêchant un flot de validation de grignoter le budget de temps dont l'importation des blocs a besoin. Avec cette protection active, le benchmark rapporte que le délai d'importation est tombé à environ 2 ms ou moins sur chaque machine testée, permettant à une limite de 300 000 gaz sous un flot de 100 transactions par seconde de rester dans le budget de traitement des blocs de 25 ms. Nethermind a une pull request ouverte implémentant ce comportement de priorisation.

Le mécanisme de suspension résout le problème d'importation des blocs mais pas celui de l'équité d'admission. Sous un flot de 100 transactions par seconde à la limite de 300 000 gaz, la machine testée la plus lente n'a admis que 12 % des transactions frame honnêtes. Lorsque le nœud suspend la validation pour traiter les blocs, le flot adversaire remplit la file de validation dans les intervalles, et les transactions honnêtes sont évincées. Le budget de traitement des blocs de 25 ms est préservé, mais l'utilité du mempool pour les émetteurs frame légitimes se dégrade fortement sous une pression adversaire soutenue.

Cet effondrement d'admission est structurellement similaire à la dynamique de spam du mempool qui a affecté Ethereum lors des périodes de mints NFT à frais élevés ou d'activité de bots d'arbitrage. L'EIP-8141 rend toutefois l'attaque moins coûteuse à maintenir, car l'adversaire n'a besoin de générer que des transactions qui atteignent la validation, et non des transactions incluses on-chain. Comme les transactions échouent à la validation, elles n'entraînent aucun coût d'inclusion pour l'attaquant au-delà du gaz consommé par validation — qui est précisément la ressource que le protocole cherche à borner.

Ce que ces résultats pourraient signifier pour les clients Ethereum et les opérateurs de nœuds

Le benchmark établit une voie crédible vers une limite de 300 000 gaz — assez élevée pour prendre en charge les transactions de confidentialité Groth16 mais pas les variantes SPHINCS+ les plus coûteuses — à condition que chaque client Ethereum majeur implémente la protection de priorité au traitement des blocs. Il s'agit d'une exigence de coordination, et non d'une règle de protocole : l'EIP lui-même n'impose pas ce comportement au client et fixe uniquement le plafond de gaz. Si une minorité de nœuds est déployée sans la protection, ces nœuds deviennent des cibles disproportionnées lors d'un flot. Cette charge de coordination est amplifiée par l'architecture multi-clients d'Ethereum, dans laquelle plusieurs équipes indépendantes maintiennent le logiciel des nœuds et le comportement à l'échelle du réseau dépend de l'implémentation de protections équivalentes par chacune.

Pour les opérateurs de nœuds utilisant du matériel situé en bas de la gamme testée par le benchmark — une machine mono-cœur avec une bande passante mémoire limitée — le résultat de 12 % d'admission des transactions honnêtes sous flot signifie que les transactions frame peuvent devenir pratiquement non fiables pendant les périodes de congestion adversaire, même sur un client entièrement à jour. Cela importe surtout pour les applications qui dépendent d'une admission rapide dans le mempool, comme les flux de transactions privées sensibles au temps ou les protocoles de coordination de signatures à seuil. Les concepteurs de protocoles construisant sur l'EIP-8141 devraient intégrer les conditions adversaires du mempool dans leurs hypothèses de vivacité, de la même manière que des protocoles DeFi comme Aave traitent le risque de latence de liquidation comme une fonction de la congestion du réseau plutôt que comme une constante.

Le benchmark n'évalue pas comme viables, sous la conception actuelle de protection à 100 transactions échouant à la validation par seconde, des limites supérieures à 300 000 gaz. Atteindre le plafond de 500 000 gaz — qui accommoderait les variantes SPHINCS+ les plus lourdes — nécessiterait un rate-limiting plus fort au niveau de la propagation des transactions, un filtrage du spam basé sur le stake, ou une hypothèse de taux de flot de base plus faible. Chacune de ces options implique une complexité protocolaire supplémentaire et une coordination inter-clients au-delà de ce que le projet EIP-8141 actuel spécifie.

Statut de draft et questions ouvertes

L'EIP-8141 est toujours en statut Draft, et les résultats du benchmark alimentent directement la discussion en cours sur les paramètres sans la résoudre. Selon le processus EIP, les propositions au stade Draft passent encore par les étapes Review et Last Call avant d'atteindre le statut Final, laissant des paramètres tels que MAX_VERIFY_GAS ouverts à révision sur la base précisément de ce type d'apport de recherche. Les développeurs de clients et les auteurs d'EIP devront peser le coût d'admission honnête de la limite de 300 000 gaz face aux cas d'usage cryptographiques nécessitant des budgets plus élevés, et déterminer si la protection de priorité au traitement des blocs suffit comme atténuation autonome ou si des mécanismes supplémentaires de résistance au spam relèvent de la proposition principale.

Le chiffre de 12 % d'admission sur la machine la plus lente sera vraisemblablement un point focal de cette discussion : un protocole qui admet moins d'une transaction honnête sur huit sous un flot modéré offre des garanties de vivacité matériellement plus faibles que le mempool actuel, même si la finalité des blocs elle-même n'est pas affectée. Le fil du forum Ethereum Research et la pull request ouverte de Nethermind sont les deux lieux documentés où cette évaluation continuera de se dérouler.