a16z : Pourquoi le pool de mémoire chiffré peine-t-il à être la solution miracle au MEV ?
TechFlow SélectionTechFlow Sélection
a16z : Pourquoi le pool de mémoire chiffré peine-t-il à être la solution miracle au MEV ?
Technologie, économie, efficacité : trois montagnes incontournables.
Dédié à des analyses Web3 approfondiesRédaction : Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Traduction : Saoirse, Foresight News
Dans les blockchains, la valeur maximale pouvant être extraite en gagnant de l'argent grâce à la décision des transactions incluses dans un bloc, exclues ou réordonnées s'appelle la « Valeur Maximale Extractible », ou MEV. Le MEV est omniprésent dans la plupart des blockchains et fait depuis longtemps l’objet d’un vaste débat au sein de l’industrie.
Note : Cet article suppose que le lecteur possède déjà une compréhension basique du MEV. Certains lecteurs peuvent souhaiter consulter préalablement notre article explicatif sur le MEV.
De nombreux chercheurs se sont interrogés en observant le phénomène MEV : la cryptographie peut-elle résoudre ce problème ? L’une des propositions consiste à utiliser un mempool chiffré : les utilisateurs diffusent des transactions chiffrées qui ne seront déchiffrées qu’après leur ordonnancement. Ainsi, le protocole de consensus doit choisir « à l’aveugle » l’ordre des transactions, ce qui semble empêcher l’exploitation des opportunités MEV lors du tri.
Mais malheureusement, que ce soit sur le plan pratique ou théorique, les mempools chiffrés ne constituent pas une solution générale au problème du MEV. Ce texte expose les difficultés rencontrées et explore les pistes envisageables pour concevoir un mempool chiffré viable.
Fonctionnement d’un mempool chiffré
Plusieurs propositions existent concernant les mempools chiffrés, mais leur cadre général est le suivant :
-
Les utilisateurs diffusent des transactions chiffrées.
-
Les transactions chiffrées sont soumises à la chaîne (dans certaines propositions, elles subissent d’abord un mélange aléatoire vérifiable).
-
Lorsqu’un bloc contenant ces transactions est finalement confirmé, les transactions sont déchiffrées.
-
Enfin, les transactions sont exécutées.
Il convient de noter que l’étape 3 (le déchiffrement) soulève une question cruciale : qui est chargé du déchiffrement ? Que se passe-t-il si le déchiffrement échoue ? Une idée simple consiste à laisser chaque utilisateur déchiffrer sa propre transaction (dans ce cas, un simple engagement masqué suffirait, sans besoin de chiffrement). Mais cette approche présente une faille : les attaquants peuvent pratiquer un MEV spéculatif.
Dans le cas du MEV spéculatif, un attaquant devine qu'une transaction chiffrée recèle une opportunité MEV, chiffre ensuite sa propre transaction et tente de l'insérer à une position avantageuse (par exemple juste avant ou après la transaction cible). Si l’ordre correspond à ses attentes, il déchiffre et extrait le MEV via sa transaction ; sinon, il refuse de déchiffrer, et sa transaction n’est pas incluse dans la blockchain finale.
On pourrait pénaliser les utilisateurs dont le déchiffrement échoue, mais mettre cela en œuvre s’avère extrêmement difficile. En effet, toutes les transactions chiffrées doivent subir la même pénalité (puisqu’elles sont indistinguables après chiffrement), et celle-ci doit être suffisamment sévère pour décourager le MEV spéculatif, même face à des cibles à forte valeur. Cela entraînerait un verrouillage massif de fonds devant rester anonymes (afin d’éviter toute corrélation entre transaction et utilisateur). Plus grave encore, un utilisateur légitime incapable de déchiffrer en raison d’un bogue logiciel ou d’une panne réseau subirait lui aussi des pertes.
La plupart des solutions proposent donc de chiffrer les transactions de façon à garantir qu’elles puissent inévitablement être déchiffrées à un moment donné, même si l’utilisateur initiateur est hors ligne ou refuse de coopérer. Cet objectif peut être atteint par plusieurs moyens :
Environnements d'exécution fiables (TEE) : Les utilisateurs peuvent chiffrer leurs transactions avec une clé détenue par une zone sécurisée d’un environnement d’exécution fiable (TEE). Dans des versions simples, le TEE sert uniquement à déchiffrer les transactions après un certain délai (ce qui nécessite que le TEE dispose d’une horloge interne). Des schémas plus complexes confient au TEE le déchiffrement des transactions et la construction des blocs, selon des critères comme l’heure d’arrivée ou les frais. Comparé aux autres schémas de mempool chiffré, le TEE permet de traiter directement des transactions en clair, réduisant ainsi les données redondantes sur la chaîne en filtrant celles qui provoqueraient un rejet. Toutefois, cet avantage repose sur la confiance matérielle.
Partage secret et chiffrement seuil (Secret-sharing and threshold encryption) : Ici, l'utilisateur chiffre sa transaction avec une clé détenue collectivement par un comité spécifique (généralement un sous-ensemble de validateurs). Le déchiffrement requiert qu'un seuil prédéfini soit atteint (par exemple, deux tiers des membres du comité).
Avec le déchiffrement seuil, la confiance passe du matériel au comité. Les partisans font remarquer que puisque la plupart des protocoles supposent déjà une majorité honnête parmi les validateurs pour le consensus, on peut faire une hypothèse similaire ici : la majorité des validateurs ne déchiffreront pas prématurément les transactions.
Cependant, une distinction cruciale existe : ces deux hypothèses de confiance ne sont pas équivalentes. Les échecs de consensus comme les bifurcations sont visibles publiquement (« faible hypothèse de confiance »), alors qu’un comité malveillant déchiffrant secrètement des transactions ne laisse aucune trace publique — une attaque indétectable et impunissable (« forte hypothèse de confiance »). Ainsi, bien que les hypothèses de sécurité semblent similaires en apparence, l’hypothèse selon laquelle « le comité ne collabore pas » est bien moins crédible en pratique.
Verrous temporels et chiffrement différé (Time-lock and delay encryption) : Alternative au chiffrement seuil, le chiffrement différé fonctionne ainsi : l’utilisateur chiffre sa transaction avec une clé publique, dont la clé privée est enfermée dans une énigme à verrou temporel. Une telle énigme est un mécanisme cryptographique où le secret n’est révélé qu’après un délai prédéfini, via une série de calculs impossibles à paralléliser. Dans ce mécanisme, n’importe qui peut résoudre l’énigme pour obtenir la clé et déchiffrer, mais seulement après avoir effectué un calcul lent (essentiellement séquentiel) conçu pour retarder suffisamment le déchiffrement jusqu’à la confirmation finale. La forme la plus puissante de ce primitif utilise la technologie du chiffrement différé pour générer publiquement ces énigmes ; on peut aussi l’approcher via un comité de confiance utilisant le chiffrement à verrou temporel, mais alors son avantage par rapport au chiffrement seuil devient discutable.
Que ce soit par chiffrement différé ou par un comité de confiance, ces solutions rencontrent de nombreux défis pratiques : premièrement, le délai dépendant du calcul, il est difficile d’en garantir la précision ; deuxièmement, elles exigent que certains acteurs utilisent du matériel haute performance pour résoudre efficacement les énigmes, mais comment les inciter à participer reste flou ; troisièmement, dans ces conceptions, toutes les transactions diffusées sont déchiffrées, y compris celles jamais inscrites dans un bloc. Contrairement aux schémas seuil (ou chiffrement par témoins), où seules les transactions incluses pourraient être déchiffrées.
Chiffrement par témoins (Witness encryption) : La solution cryptographique la plus avancée est le « chiffrement par témoins ». Théoriquement, ce mécanisme chiffre une information de sorte que seul celui connaissant un « témoin » relatif à une relation NP spécifique puisse la déchiffrer. Par exemple, seule la personne capable de résoudre une grille de sudoku ou de fournir un antécédent à un hachage donné peut déchiffrer.
(Note : Une relation NP est un lien entre un « problème » et une « réponse » qui peut être rapidement vérifiée.)
Pour toute relation NP, une logique similaire peut être implémentée via des SNARKs. On peut dire que le chiffrement par témoins crypte les données de manière à ce que seuls ceux capables de produire une preuve SNARK satisfaisant une condition donnée puissent déchiffrer. Dans le contexte d’un mempool chiffré, une telle condition typique serait : les transactions ne peuvent être déchiffrées qu’après la confirmation finale du bloc.
Ce primitif théorique est très prometteur. En réalité, c’est une solution universelle dont les méthodes seuil ou différées ne sont que des instanciations. Malheureusement, aucune mise en œuvre pratique du chiffrement par témoins n’existe aujourd’hui. Même si elle existait, il serait difficile de dire qu’elle offrirait un avantage significatif sur les méthodes seuil dans une chaîne de type proof-of-stake. Même en configurant le chiffrement par témoins pour n’autoriser le déchiffrement qu’après confirmation finale dans un bloc, un comité malveillant pourrait toujours simuler secrètement le protocole de consensus pour falsifier cet état de confirmation, puis utiliser cette chaîne privée comme « témoin » pour déchiffrer. Dans ce cas, un déchiffrement seuil mené par le même comité offrirait une sécurité équivalente tout en étant bien plus simple.
Cependant, dans les protocoles de consensus proof-of-work, l’avantage du chiffrement par témoins est plus marqué. Car même un comité entièrement malveillant ne pourrait miner secrètement plusieurs nouveaux blocs à partir de la tête actuelle de la chaîne pour falsifier la confirmation.
Défis techniques des mempools chiffrés
Plusieurs obstacles pratiques limitent la capacité des mempools chiffrés à contrer le MEV. Globalement, la confidentialité de l’information est en soi un défi. Il est important de noter que la cryptographie est peu utilisée dans Web3, mais nos décennies d’expérience dans le déploiement de chiffrement sur les réseaux (comme TLS/HTTPS) et les communications privées (de PGP aux plateformes modernes comme Signal ou WhatsApp) ont largement exposé les difficultés : le chiffrement protège la confidentialité, mais ne garantit jamais l’absolu.
Premièrement, certains acteurs peuvent accéder directement au contenu en clair des transactions des utilisateurs. Typiquement, les utilisateurs ne chiffrent pas eux-mêmes leurs transactions, mais délèguent cette tâche à leur fournisseur de portefeuille. Celui-ci obtient alors accès au contenu clair, pouvant potentiellement l’exploiter ou le vendre pour extraire du MEV. La sécurité du chiffrement dépend toujours de tous les détenteurs de clés. L’étendue du contrôle des clés définit la limite de sécurité.
Ensuite, le plus grand problème vient des métadonnées, c’est-à-dire les données non chiffrées entourant la charge utile chiffrée (la transaction). Les searchers peuvent exploiter ces métadonnées pour deviner l’intention de la transaction et pratiquer un MEV spéculatif. Ils n’ont pas besoin de comprendre parfaitement la transaction ni de réussir à chaque fois. Par exemple, s’ils peuvent estimer avec une probabilité raisonnable qu’une transaction est un ordre d’achat sur un DEX particulier, cela suffit pour lancer une attaque.
On peut classer les métadonnées en deux catégories : les problèmes classiques inhérents au chiffrement, et les problèmes spécifiques aux mempools chiffrés.
-
Taille des transactions : Le chiffrement ne cache pas la taille du message en clair (notons que la définition formelle de la sécurité sémantique exclut explicitement la dissimulation de la taille). C’est un vecteur d’attaque classique : par exemple, même chiffré, un espion peut déterminer en temps réel le contenu d’un flux Netflix en observant la taille de chaque paquet. Dans un mempool chiffré, certains types de transactions peuvent avoir une taille distinctive, trahissant ainsi des informations.
-
Heure de diffusion : Le chiffrement ne masque pas non plus les informations temporelles (un autre vecteur classique). Dans les scénarios Web3, certains émetteurs (comme dans les ventes structurées) peuvent envoyer des transactions à intervalles réguliers. L’heure peut aussi être corrélée à d’autres événements, comme l’activité d’une bourse externe ou une actualité. Un usage plus subtil concerne l’arbitrage entre bourses centralisées (CEX) et décentralisées (DEX) : le séquenceur peut insérer une transaction créée le plus tard possible pour profiter du prix CEX le plus récent, tout en excluant toutes les autres transactions diffusées après un certain moment (même chiffrées), assurant ainsi à sa transaction un avantage de prix exclusif.
-
Adresse IP source : Les searchers peuvent surveiller le réseau pair-à-pair et tracer les adresses IP sources pour identifier l’expéditeur. Ce problème est connu depuis les débuts du Bitcoin (il y a plus de dix ans). Si un expéditeur a un comportement régulier, cela devient très précieux pour les searchers. Par exemple, connaître l’identité permet de lier une transaction chiffrée à des transactions historiques déchiffrées.
-
Expéditeur, frais et informations gas : Les frais de transaction sont un type de métadonnées propre aux mempools chiffrés. Sur Ethereum, une transaction classique inclut l’adresse de l’expéditeur (pour payer les frais), le budget maximum en gas et le prix unitaire du gas que l’expéditeur accepte de payer. Comme l’adresse réseau source, l’adresse d’envoi peut servir à corréler plusieurs transactions à une entité réelle ; le budget en gas peut suggérer l’intention. Par exemple, interagir avec un DEX spécifique peut nécessiter une quantité fixe identifiable de gas.
Des searchers sophistiqués peuvent combiner plusieurs de ces types de métadonnées pour prédire le contenu des transactions.
Théoriquement, toutes ces informations peuvent être cachées, mais au prix de performances et de complexité. Par exemple, remplir les transactions à une taille standard masque leur taille, mais gaspille bande passante et espace sur chaîne ; ajouter un délai avant envoi masque le timing, mais augmente la latence ; soumettre via un réseau anonyme comme Tor masque l’IP, mais crée de nouveaux défis.
Les métadonnées les plus difficiles à cacher sont les informations relatives aux frais. Chiffrer les données de frais pose de graves problèmes aux constructeurs de blocs : d’abord, le problème du spam : si les frais sont chiffrés, n’importe qui peut diffuser des transactions chiffrées mal formatées, qui seront triées mais incapables de payer, et impossible à sanctionner après déchiffrement. Cela pourrait être résolu via des SNARKs (prouver que la transaction est valide et solvable), mais cela augmenterait fortement les coûts.
Ensuite, l’efficacité de la construction de blocs et des enchères de frais. Les constructeurs utilisent les frais pour créer des blocs maximisant leurs profits et déterminer le prix courant des ressources sur chaîne. Chiffrer les frais ruine ce processus. Une solution serait de fixer des frais par bloc, mais cela serait économiquement inefficace et pourrait engendrer un marché secondaire pour l’inclusion, contredisant l’objectif initial du mempool chiffré. Une autre option serait une enchère de frais via un calcul multipartite sécurisé ou du matériel fiable, mais ces deux options sont très coûteuses.
Enfin, un mempool chiffré sécurisé augmente les coûts système de multiples façons : le chiffrement augmente la latence, la charge de calcul et la consommation de bande passante ; son intégration avec des objectifs futurs comme le sharding ou l’exécution parallèle reste floue ; il peut introduire de nouveaux points de défaillance pour la vivacité (comme les comités de déchiffrement seuil ou les solveurs de fonctions différées) ; et la complexité de conception et d’implémentation grimpe fortement.
Beaucoup des problèmes des mempools chiffrés rejoignent ceux rencontrés par les blockchains axées sur la confidentialité des transactions (comme Zcash ou Monero). S’il y a un aspect positif, c’est que résoudre tous les défis du chiffrement pour atténuer le MEV éliminerait aussi les obstacles à la confidentialité transactionnelle.
Défis économiques des mempools chiffrés
Enfin, les mempools chiffrés font face à des défis économiques. Contrairement aux défis techniques, qui peuvent être progressivement atténués par un effort d’ingénierie, ces obstacles économiques sont fondamentaux et extrêmement difficiles à résoudre.
Le cœur du problème MEV provient de l’asymétrie d’information entre les créateurs de transactions (les utilisateurs) et les extracteurs d’opportunités MEV (les searchers et les constructeurs de blocs). Les utilisateurs ignorent souvent la valeur extractible dans leurs transactions. Ainsi, même avec un mempool chiffré parfait, ils pourraient être incités à divulguer leur clé de déchiffrement contre une récompense inférieure à la valeur réelle du MEV, phénomène appelé « déchiffrement incitatif ».
Ce scénario n’est pas improbable, car des mécanismes similaires existent déjà, comme MEV Share. MEV Share est un mécanisme d’enchères de flux d’ordres permettant aux utilisateurs de soumettre volontairement des informations transactionnelles à un pool, où des searchers s’affrontent pour le droit d’exploiter cette opportunité MEV. Le gagnant extrait le MEV puis reverse une partie du profit (montant de l’enchère ou un pourcentage) à l’utilisateur.
Ce modèle peut s’adapter directement au mempool chiffré : l’utilisateur doit divulguer sa clé de déchiffrement (ou une partie) pour participer. Mais la plupart des utilisateurs ne perçoivent pas le coût d’opportunité de cette participation ; ils voient seulement le gain immédiat et sont heureux de divulguer. Dans la finance traditionnelle, on trouve des cas similaires : par exemple, la plateforme sans commission Robinhood tire ses profits en vendant le flux d’ordres à des tiers via le « payment-for-order-flow ».
Un autre scénario possible est qu’un gros constructeur oblige les utilisateurs à divulguer le contenu (ou des informations) de leur transaction sous prétexte de censure. La résistance à la censure est un sujet important et controversé dans Web3, mais si de grands validateurs ou constructeurs sont soumis à des obligations légales (comme les règles du OFAC américain) exigeant de censurer certaines listes, ils pourraient refuser de traiter toute transaction chiffrée. Techniquement, l’utilisateur pourrait utiliser une preuve à divulgation nulle pour prouver que sa transaction chiffrée respecte les règles, mais cela ajoute coût et complexité. Même si la blockchain garantit l’inclusion des transactions chiffrées (résistance forte à la censure), les constructeurs pourraient prioriser les transactions en clair au début du bloc, plaçant les transactions chiffrées à la fin. Ainsi, les transactions nécessitant une priorité d’exécution seraient finalement contraintes de divulguer leur contenu.
Autres défis d’efficacité
Les mempools chiffrés augmentent de multiples façons évidentes la charge système. Les utilisateurs doivent chiffrer leurs transactions, et le système doit les déchiffrer, ce qui augmente les coûts de calcul et peut agrandir la taille des transactions. Comme mentionné, la gestion des métadonnées aggrave encore ces coûts. Mais certains coûts d’efficacité sont moins évidents. En finance, un marché est dit efficace si les prix reflètent toute l’information disponible ; les retards et asymétries d’information rendent le marché inefficace. C’est précisément le résultat inévitable d’un mempool chiffré.
Cette inefficacité a une conséquence directe : une incertitude accrue sur les prix, résultant directement du délai supplémentaire introduit par le chiffrement. Par conséquent, davantage de transactions pourraient échouer en raison d’un dépassement de glissement de prix, gaspillant ainsi de l’espace sur chaîne.
De même, cette incertitude de prix pourrait favoriser les transactions MEV spéculatives cherchant à tirer profit d’arbitrages sur chaîne. Notons que les mempools chiffrés pourraient rendre ces opportunités plus fréquentes : à cause du délai d’exécution, l’état courant d’un DEX devient plus flou, ce qui risque de réduire l’efficacité du marché et d’engendrer des écarts de prix entre plateformes. Ces transactions MEV spéculatives gaspillent aussi de l’espace bloc, car elles s’interrompent souvent si aucune opportunité d’arbitrage n’est trouvée.
Résumé
L’objectif de cet article était de recenser les défis des mempools chiffrés afin de recentrer les efforts vers d’autres solutions, mais les mempools chiffrés pourraient néanmoins faire partie d’une stratégie de gestion du MEV.
Une piste envisageable est un design hybride : certaines transactions passent par un mempool chiffré pour un « tri à l’aveugle », d’autres utilisent d’autres méthodes. Pour certains types de transactions (par exemple, les ordres importants de grands acteurs du marché, capables de chiffrer ou de remplir minutieusement leurs transactions et prêts à payer un coût plus élevé pour éviter le MEV), un design hybride pourrait être adapté. Cela aurait aussi un sens pour des transactions très sensibles (comme les correctifs pour des contrats vulnérables).
Toutefois, en raison de limitations techniques, de la complexité élevée et des coûts en performance, les mempools chiffrés ne seront probablement pas la solution miracle tant attendue contre le MEV. La communauté doit développer d'autres approches, notamment des enchères MEV, des mécanismes de défense au niveau applicatif et la réduction du temps de confirmation finale. Le MEV restera un défi pendant un certain temps, nécessitant des recherches approfondies pour trouver un équilibre entre diverses solutions afin d’en atténuer les effets négatifs.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
a16z
