À propos des limites des mempools chiffrés

La valeur susceptible d’être extraite par l’inclusion, l’exclusion ou la réorganisation des transactions au sein d’un bloc est désignée sous le terme de « valeur extractible maximale », ou MEV. La MEV est courante sur la plupart des blockchains et suscite un intérêt marqué ainsi que de nombreux débats dans la communauté.

Remarque : Ce billet suppose une compréhension de base de la MEV. Certains lecteurs préféreront peut-être commencer par notre guide sur la MEV.

Face à la problématique MEV, de nombreux chercheurs ont posé une question essentielle : la cryptographie peut-elle résoudre ce problème ? L’une des pistes explorées est celle du mempool chiffré, dans lequel les utilisateurs diffusent des transactions chiffrées qui ne sont révélées qu’après l’ordonnancement. Le protocole de consensus doit alors s’engager sur un ordre des transactions à l’aveugle, ce qui, en apparence, empêche la capture d’opportunités MEV pendant le processus de classement.

Or, pour des raisons aussi bien pratiques que théoriques, nous ne considérons pas que les mempools chiffrés puissent constituer une solution universelle à la MEV. Nous exposons ci-dessous les difficultés rencontrées et analysons les méthodes envisageables pour concevoir de tels mempools.

Principe de fonctionnement des mempools chiffrés

Bien que de nombreuses variantes aient été proposées, l’architecture générale d’un mempool chiffré s’articule comme suit :

1. Les utilisateurs transmettent leurs transactions chiffrées.
2. Les transactions chiffrées sont validées on-chain (dans certaines approches, après avoir été mélangées aléatoirement de façon prouvable).
3. Une fois le bloc d’engagement finalisé, les transactions sont déchiffrées.
4. Enfin, elles sont exécutées.

L’étape 3 — le déchiffrement des transactions — est cruciale : qui procède au déchiffrement, et que se passe-t-il si celui-ci n’est pas mené à terme ? Demander naïvement aux utilisateurs de déchiffrer eux-mêmes leurs transactions reviendrait, au fond, à simplement dissimuler des engagements, sans réel chiffrement. Cette solution est cependant vulnérable : elle s’expose au MEV spéculatif.

Dans une attaque de MEV spéculatif, un acteur tente de deviner qu’une transaction chiffrée donnera accès à une opportunité de capture de valeur. Il chiffre alors ses propres transactions, dans l’espoir qu’elles soient positionnées de manière avantageuse (par exemple juste avant ou après la transaction ciblée). Si la séquence correspond à ses attentes, il procède au déchiffrement et capture la MEV ; dans le cas contraire, il s’abstient de déchiffrer, et sa transaction est écartée de la chaîne.

Il serait possible d’instaurer des sanctions pour le non-décryptage, mais leur application est délicate. La pénalité devrait être uniforme pour toutes les transactions chiffrées (puisqu’elles sont indifférenciables), mais aussi suffisamment dissuasive, même face à des opportunités de MEV très lucratives. Cela supposerait de mobiliser d’importants capitaux, tout en maintenant leur anonymat afin de préserver la confidentialité de l’identité des utilisateurs. Par ailleurs, des utilisateurs honnêtes pourraient se retrouver pénalisés en cas de bug ou d’incident réseau les empêchant de procéder à un déchiffrement légitime.

La plupart des solutions privilégient donc un chiffrement garantissant le déchiffrement futur, même en cas d’indisponibilité ou de non-coopération de l’utilisateur à l’origine de la transaction. Plusieurs mécanismes sont envisageables :

TEE : Les utilisateurs chiffrent leurs transactions à l’aide d’une clé détenue par une enclave TEE (Trusted Execution Environment, environnement d’exécution de confiance). Pour certains, la TEE ne servirait qu’à déchiffrer après une échéance temporelle (ce qui suppose la gestion du temps au sein de l’enclave). Des méthodes plus avancées proposent de confier à la TEE le déchiffrement puis l’ordonnancement du bloc selon des critères comme l’ordre d’arrivée ou le niveau de frais. L’un des avantages d’une TEE — par rapport à d’autres modèles — est la possibilité de traiter les transactions en clair, limitant ainsi le spam on-chain grâce au filtrage en amont des transactions vouées à l’échec. L’inconvénient majeur demeure la nécessité d’accorder une confiance forte au matériel.

Partage de secret et chiffrement à seuil : Cette stratégie consiste à chiffrer à une clé partagée par un comité, typiquement un sous-ensemble de validateurs, et nécessite un seuil (ex. deux tiers du comité) pour assurer le déchiffrement.

La version la plus simple prévoit une nouvelle clé de déchiffrement collective à chaque tour (bloc ou époque, comme sur Ethereum), reconstituée et publiée par le comité une fois les transactions ordonnées dans un bloc finalisé. Ce procédé repose sur un partage de secret classique. L’inconvénient : il dévoile toutes les transactions du mempool, y compris celles non incluses dans un bloc, et impose une génération de clé distribuée (DKG) à chaque tour.

Pour renforcer la confidentialité, il est préférable de ne déchiffrer que les transactions réellement intégrées au bloc. Le chiffrement à seuil permet cette flexibilité, avec la possibilité d’amortir le coût des générations de clés en conservant la même clé sur plusieurs blocs, le déchiffrement à seuil du comité n’intervenant qu’après finalisation. Cette approche exige cependant une charge de travail accrue pour le comité : naïvement, le volume de calcul est proportionnel au nombre de transactions à déchiffrer, même si des travaux récentssuggèrent des procédés de déchiffrement par lots bien plus efficaces.

Le chiffrement à seuil transfère la confiance du matériel vers un comité d’acteurs. Faut-il supposer que, puisque les protocoles de consensus reposent déjà sur une majorité honnête de validateurs, on puisse s’en remettre à la bonne foi d’un comité de déchiffrement ? La prudence s’impose : ces deux niveaux de confiance diffèrent. Les incidents de consensus, comme le fork de la chaîne, sont visibles publiquement (faible niveau d’exigence), tandis qu’un déchiffrement prématuré malveillant peut rester invisible (niveau d’exigence fort). En pratique, la confiance dans la non-collusion du comité n’est donc pas vraiment la même que celle accordée au consensus.

Chiffrement retardé et time-lock : Alternative, le chiffrement retardé consiste à chiffrer les transactions à l’aide d’une clé publique dont la clé privée est « enfermée » dans une énigme cryptographique temporisée. Ce mécanisme ne révèle le secret qu’après un délai défini, le déchiffrement n’étant possible qu’au terme d’un calcul séquentiel non parallélisable. Toute personne est ensuite en mesure de découvrir la clé et de déchiffrer la transaction, mais uniquement après ce calcul lent, conçu pour empêcher tout déchiffrement prématuré. Le schéma le plus abouti recourt au chiffrement retardé généré publiquement ; à défaut, un comité de confiance peut calculer l’énigme, mais l’avantage sur le chiffrement à seuil s’en trouve alors ténu.

Chiffrement retardé ou comité : dans les deux cas, des problèmes pratiques émergent. D’abord, il est complexe de contrôler finement le moment de déchiffrement, le délai étant purement computationnel. Ensuite, ces schémas exigent qu’un acteur résolve efficacement les énigmes via du matériel spécialisé. Même si ce rôle est ouvert, il demeure difficile d’en garantir l’exécution (et donc la bonne incitation). Enfin, avec ce type de conception, toutes les transactions diffusées sont déchiffrées, y compris celles jamais intégrées à un bloc ; seules les solutions à seuil (ou à chiffrement témoin) permettent, potentiellement, de ne déchiffrer que les transactions prises en compte.

Chiffrement témoin : L’approche cryptographique la plus avancée intègre le chiffrement témoin. Sur le plan théorique, ce schéma permet de chiffrer à l’intention de quiconque détient le témoin d’une relation NP particulière. Par exemple, on peut chiffrer de manière à ce que seule la personne connaissant la solution d’un sudoku, ou la préimage d’un certain hachage, puisse accéder au secret.

Cette propriété s’étend à l’usage des SNARKs pour toute relation NP : le chiffrement témoin revient à chiffrer pour toute entité capable de produire une preuve SNARK d’une condition donnée. Dans le cas du mempool chiffré, cela permettrait de restreindre le déchiffrement aux transactions d’un bloc finalisé.

Il s’agit là d’un outil théorique puissant, généralisant les approches par comité ou temporisation. Mais il n’existe à ce jour aucune implémentation pratique de chiffrement témoin. Et même si c’était le cas, il n’est pas certain que cette solution dépasse en intérêt l’approche par comité pour une blockchain en proof-of-stake. En effet, un comité malveillant peut simuler en privé la finalisation, puis s’appuyer sur cette chaîne cachée pour déchiffrer les transactions avant l’heure. Finalement, le chiffrement à seuil par ce même comité offre un niveau de sécurité équivalent, pour une complexité bien moindre.

Le chiffrement témoin présente un avantage plus net dans les protocoles de consensus proof-of-work, car même un comité complètement malveillant ne peut « miner » en privé plusieurs blocs afin de simuler la finalité.

Enjeux techniques liés aux mempools chiffrés

Le déploiement de mempools chiffrés se heurte à de nombreux défis pratiques majeurs pour l’atténuation de la MEV. De manière générale, assurer la confidentialité est particulièrement complexe. Fait notable : la cryptographie reste peu répandue dans l’univers web3, alors même que l’expérience acquise sur le chiffrement web (TLS/HTTPS) et la confidentialité des communications (PGP, Signal, Whatsapp) met en lumière de multiples écueils. Le chiffrement, bien qu’efficace pour préserver la confidentialité, ne l’assure jamais totalement.

Première difficulté : certaines parties peuvent obtenir le texte en clair d’une transaction. Il arrive souvent que l’utilisateur délègue le chiffrement à son wallet, qui détient alors l’information brute et peut l’exploiter à son profit pour extraire la MEV. Un schéma de chiffrement ne protège jamais mieux que le plus faible des détenteurs de la clé.

Au-delà, la question cruciale concerne les métadonnées, c’est-à-dire les informations périphériques à la transaction transmise, mais non chiffrées. Les chercheurs de MEV peuvent s’appuyer sur ces éléments pour tenter d’inférer l’intention de la transaction et spéculer. Ils n’ont pas besoin d’une compréhension détaillée, ni d’avoir raison à chaque fois ; il leur suffit par exemple de déduire — avec une probabilité raisonnable — qu’une transaction correspond à un ordre d’achat sur un DEX donné.

On distingue plusieurs familles de métadonnées, certaines classiques dans le contexte du chiffrement, d’autres propres aux mempools chiffrés.

• Taille de la transaction : Le chiffrement ne masque pas la taille du message chiffré. (Les définitions formelles de la sécurité sémantique ne cherchent pas à cacher la taille du texte d’origine.) Il s’agit d’un angle d’attaque classique. Par exemple, un observateur peut deviner en temps réel, à partir de la taille des paquets, quelle vidéo est visionnée sur Netflix, malgré le chiffrement. Pour un mempool chiffré, certains formats transactionnels trahissent leur nature par la taille.

• Moment d’émission : Le chiffrement ne masque pas non plus l’heure de diffusion (autre vecteur d’attaque classique). Dans web3, certains expéditeurs effectuent des transactions à intervalles réguliers (par exemple, lors de ventes structurées). Le timing peut aussi être corrélé avec des événements externes (activité sur les exchanges, actualités). Plus subtilement, dans l’arbitrage CEX/DEX, un séquenceur peut tirer parti du fait d’attendre le plus longtemps possible pour insérer une transaction basée sur l’actualité des prix, tout en bloquant celles diffusées après un instant donné. Il assure ainsi à sa propre transaction l’exploitation optimale de l’information la plus récente.

• Adresse IP source : Les acteurs MEV peuvent surveiller le réseau P2P et associer une adresse IP à un expéditeur. Cette faille a été mise en lumière il y a plus de dix ans sur Bitcoin. Cela facilite la corrélation entre transactions chiffrées et transactions précédemment déchiffrées, révélant les comportements des utilisateurs.

• Adresse d’expéditeur et paramètres de frais/gas : Enfin, les frais de transaction constituent une métadonnée propre aux mempools chiffrés. Sur Ethereum, chaque transaction mentionne l’adresse payeuse, le budget gas maximal et le prix unitaire de gas. L’adresse – comme l’adresse réseau – permet le rapprochement de transactions et l’identification d’entités réelles, tandis que le budget gas donne des indices sur la nature de la transaction (par exemple, l’interaction avec un DEX requiert typiquement un niveau précis de gas).

Les chercheurs de MEV les plus aguerris recourent volontiers à la combinaison de plusieurs types de métadonnées pour prédire le contenu d’une transaction.

Toutes ces informations peuvent, en théorie, être occultées, mais toujours au prix d’un surcoût en performance et en complexité. Par exemple, le fait de rembourrer toutes les transactions jusqu’à une taille standard masque la taille brute, mais gaspille bande passante et espace on-chain. Ajouter un délai artificiel avant la diffusion dissimule le timing, mais impacte la latence. L’utilisation d’un réseau d’anonymat comme Tor masque l’adresse IP, mais soulève d’autres problématiques.

La donnée la plus critique reste celle relative aux frais. Son chiffrement soulève deux défis majeurs pour les constructeurs de blocs. Premièrement : le spam. Si la preuve de paiement des frais est masquée, n’importe qui peut publier des transactions dont le paiement effectif ne pourra être vérifié qu’en fin de procédure ; elles seront alors simplement ignorées, sans sanction pour leur auteur. Cela pourrait être réglé par des preuves SNARK de validité et de financement, mais cela engendrerait une forte complexité supplémentaire.

Deuxième enjeu : la construction efficace des blocs et la formation des prix via les enchères de frais. Les constructeurs utilisent ces informations pour maximiser la rentabilité du bloc et refléter le prix de marché des ressources on-chain. En chiffrant ces données, on désorganise le mécanisme. Il serait envisageable d’imposer un forfait uniforme par bloc, mais ce mode d’allocation est économiquement sous-optimal et risque de favoriser l’émergence de marchés secondaires, ce qui va à l’encontre de l’objectif d’un mempool chiffré. Organiser des enchères via un calcul multipartite sécurisé ou du matériel de confiance est possible, mais coûte cher.

Enfin, les mempools chiffrés génèrent une surcharge sur la chaîne : latence accrue, complexité calculatoire et consommation de bande passante. Leur articulation avec le sharding ou l’exécution parallèle — axes majeurs d’évolution pour les blockchains — pose des défis d’intégration. Cela multiplie aussi les risques de rupture de vivacité (par exemple, du fait d’un comité de déchiffrement défaillant ou d’un solveur de fonction temporisée) et alourdit significativement les exigences d’ingénierie.

Les problématiques évoquées ne sont pas propres aux mempools chiffrés : on les retrouve aussi sur les blockchains soucieuses de garantir la confidentialité transactionnelle (Zcash, Monero…). Un avantage secondaire à la résolution de ces défis pour limiter la MEV serait, de fait, la levée des obstacles techniques à la confidentialité transactionnelle dans son ensemble.

Enjeux économiques des mempools chiffrés

Les mempools chiffrés se heurtent aussi à des limites économiques structurelles. Là où les obstacles techniques pourraient, dans une certaine mesure, être surmontés via l’ingénierie, les enjeux économiques s’avèrent fondamentaux.

Fondamentalement, la MEV provient d’une asymétrie d’information entre les utilisateurs (créateurs de transactions) et les chercheurs/constructeurs (découvreurs d’opportunités MEV). Les utilisateurs ignorent généralement la valeur réelle de la MEV associée à leur transaction. Par conséquent, même dans un schéma de mempool chiffré idéal, ils pourraient être incités à céder leur clé de déchiffrement en échange d’un paiement inférieur à la valeur extraite. C’est ce que l’on nomme le déchiffrement incité.

Ce scénario se retrouve déjà dans la solution MEV Share, une enchère de flux d’ordres où les utilisateurs soumettent, de façon sélective, des informations sur leurs transactions à un pool concurrentiel. L’offre la plus élevée permet au chercheur d’extraire la MEV, tout en restituant une fraction des gains à l’utilisateur.

Un tel modèle pourrait être rapidement transplanté dans l’univers des mempools chiffrés, en demandant aux utilisateurs de révéler leurs clés (ou une partie des informations) pour accéder au système. La plupart ne saisiront pas le coût d’opportunité — ils ne verront que la récompense versée, et n’hésiteront pas à divulguer des informations confidentielles. Ce principe est courant dans la finance traditionnelle : par exemple, les courtiers proposant du trading sans frais (Robinhood…) se rémunèrent en revendant le flux d’ordres (« payment-for-order-flow ») à des tiers.

D’autres scénarios probables impliquent de grands constructeurs qui imposent la divulgation totale ou partielle des transactions des utilisateurs à des fins de censure. La résistance à la censure est un enjeu crucial dans le web3. Toutefois, si les principaux proposeurs/constructeurs sont légalement contraints de respecter une liste noire (par exemple, imposée par l’OFAC, voir ici), ils pourraient se refuser à traiter toute transaction chiffrée. Ce problème pourrait être partiellement compensé sur le plan technique si les utilisateurs produisent une preuve Zero-Knowledge de conformité, mais au prix d’une complexité accrue et de surcoûts. Même dans une architecture supposée très résistante à la censure – où l’inclusion de transactions chiffrées serait garantie – les constructeurs de blocs pourraient toujours privilégier les transactions connues (en clair) et reléguer à la fin du bloc celles chiffrées. Toute transaction nécessitant une garantie d’exécution pourrait donc être amenée à dévoiler son contenu, malgré les mécanismes de confidentialité.

Autres problèmes d’efficacité

Les mempools chiffrés pèsent naturellement sur l’efficacité globale du système. Les utilisateurs doivent chiffrer les transactions, qui sont ensuite déchiffrées par le réseau, ce qui renchérit la charge computationnelle et peut allonger les messages. Comme nous l’avons signalé, la gestion des métadonnées accroît encore ces contraintes. D’autres effets sont moins évidents : sur les marchés financiers, l’efficience s’entend de la capacité du prix à refléter l’ensemble des informations disponibles. Dès lors que l’on introduit des délais et des asymétries d’information – ce qui est le cas avec un mempool chiffré – l’efficience du marché se dégrade.

Une conséquence directe est l’accroissement de l’incertitude de prix, générée par le délai supplémentaire dans la validation des transactions. Cela multiplie les échecs de transactions dus au dépassement de la tolérance au slippage, ce qui gaspille des ressources sur la chaîne.

De même, cette incertitude accrue peut favoriser la prolifération de transactions MEV spéculatives cherchant à exploiter les arbitrages on-chain. Avec un mempool chiffré, ces occasions pourraient se multiplier, puisque le délai d’exécution fragilise encore plus l’efficience du marché, faisant émerger des écarts de prix entre plateformes. Ces transactions MEV de nature spéculative consommeront de l’espace dans les blocs, sans forcément aboutir si l’opportunité ne se présente pas.

Notre objectif étant de décrire les principaux défis des mempools chiffrés pour orienter la communauté vers des solutions alternatives, il faut toutefois reconnaître que ces dispositifs pourraient s’intégrer à une stratégie globale de lutte contre la MEV.

Un compromis envisageable réside dans les solutions hybrides, combinant l’ordonnancement à l’aveugle de certaines transactions via un mempool chiffré, et l’ordonnancement classique pour d’autres. Pour les transactions importantes — telles que des ordres d’achat/vente de gros acteurs pouvant soigner leur chiffrement et disposés à payer un surcoût pour éviter la MEV — ou pour les opérations hautement sensibles (ex. corrections de failles dans des contrats de sécurité), ce schéma hybride peut être judicieux.

Néanmoins, en raison de leurs limites structurelles, de l’ingénierie nécessaire et du poids qu’ils font peser sur la performance, les mempools chiffrés ne sauraient être considérés comme la solution ultime au MEV. La communauté devra s’atteler au développement d’autres solutions : enchères MEV, protections au niveau applicatif, réduction du temps de finalité. La MEV restera un défi de long terme, et seul un travail rigoureux permettra d’assembler les bons outils pour en limiter les effets négatifs.

Pranav Garimidi est Research Associate chez a16z Crypto. Il conduit des recherches sur la conception de mécanismes et la théorie algorithmique des jeux appliquées aux systèmes blockchain, avec un intérêt particulier pour l’interaction des incitations à chaque couche de la pile blockchain. Avant de rejoindre a16z, il était étudiant à l’Université Columbia, où il a été diplômé en informatique.

Joseph Bonneau est professeur associé au département d’informatique du Courant Institute (NYU) et conseiller technique auprès de a16z crypto. Ses travaux portent sur la cryptographie appliquée et la sécurité des blockchains. Il a enseigné les cryptomonnaies à l’Université de Melbourne, NYU, Stanford et Princeton. Il est diplômé d’un doctorat à l’Université de Cambridge ainsi que d’une licence et d’un master de Stanford.

Lioba Heimbach est doctorante en quatrième année sous la direction du Prof. Dr. Roger Wattenhofer, au sein du groupe Distributed Computing (Disco) à l’ETH Zurich. Ses recherches portent sur les protocoles blockchain, en particulier la finance décentralisée (DeFi). Elle s’attache à favoriser un écosystème blockchain et DeFi accessible, décentralisé, équitable et efficace. Elle a effectué un stage de recherche chez a16z crypto à l’été 2024.

Les opinions exprimées dans cet article sont celles des personnes citées de AH Capital Management, L.L.C. (« a16z ») et ne reflètent pas celles de a16z ou de ses filiales. Certains éléments mentionnés proviennent de sources tierces, notamment de sociétés en portefeuille de fonds gérés par a16z. S’ils sont réputés fiables, a16z n’a pas procédé à une vérification indépendante de leur exactitude, ni de leur pertinence pour une situation donnée. Ce contenu peut inclure de la publicité de tiers ; a16z n’a pas examiné ces publicités et n’approuve aucun contenu promotionnel y figurant.

Ce contenu est fourni à titre informatif uniquement et ne doit pas être interprété comme un conseil juridique, professionnel, fiscal ou d’investissement. Il vous revient de consulter vos propres conseillers à ce sujet. Toute référence à des valeurs mobilières ou actifs numériques a un but purement illustratif et ne constitue en rien une recommandation d’investissement ou une offre de service en investissement. Ce contenu ne s’adresse pas, et n’est pas destiné à servir de base, à des investisseurs ou prospects ; il ne saurait être utilisé pour prendre une décision d’investissement dans un fonds a16z. (Toute proposition d’investissement dans un fonds a16z ne peut se faire que via la documentation officielle du fonds, lue dans son intégralité.) Les investissements ou sociétés mentionnés ne sont pas représentatifs de l’ensemble du portefeuille a16z ; aucune garantie n’est donnée quant à leur rentabilité, ni quant à la reproductibilité de ces caractéristiques à l’avenir. La liste des investissements de fonds Andreessen Horowitz (hors cas non divulgués publiquement ou investissements non annoncés en actifs numériques cotés) est disponible sur https://a16z.com/investments/.

Les informations sont à jour à la date de publication. Toute projection, estimation, prévision, opinion ou objectif formulé dans ce document est susceptible d’évoluer sans préavis et peut différer d’autres points de vue. Consultez https://a16z.com/disclosures pour des informations complémentaires importantes.

Mentions légales :

1. Cet article est reproduit depuis [a16zcrypto]. Tous droits réservés aux auteurs originaux [Pranav GarimidiJoseph BonneauLioba Heimbach]. Pour toute contestation relative à cette reproduction, veuillez contacter l’équipe Gate Learn afin qu’elle procède à un examen rapide.
2. Avertissement : Les points de vue exprimés dans cet article relèvent exclusivement de l’auteur et ne constituent en aucun cas un conseil d’investissement.
3. La traduction de l’article dans d’autres langues est réalisée par l’équipe Gate Learn. Sauf mention contraire, la copie, la diffusion ou le plagiat de ces traductions sont interdits.