a16z : Pourquoi le pool de mémoire chiffré est-il difficile de devenir le remède universel contre le MEV ?

Technologie, économie, efficacité : trois montagnes incontournables.

Rédaction : Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z

Compilation : Saoirse, Foresight News

Dans la blockchain, la capacité de gagner de l'argent en décidant quelles transactions seront incluses dans un bloc, lesquelles seront exclues, ou en ajustant l'ordre des transactions est appelée « valeur maximale pouvant être extraite », abrégée en MEV. Le MEV est omniprésent dans la plupart des blockchains et a toujours été un sujet de préoccupation et de discussion dans l'industrie.

Remarque : Cet article suppose que le lecteur a une compréhension de base de l'MEV. Certains lecteurs peuvent d'abord lire notre * article de vulgarisation sur l'MEV.*

De nombreux chercheurs, en observant le phénomène MEV, ont posé une question claire : la technologie cryptographique peut-elle résoudre ce problème ? Une des solutions consiste à utiliser un pool de mémoire cryptée : les utilisateurs diffusent des transactions cryptées, qui ne seront décryptées et révélées qu'après avoir été triées. Ainsi, le protocole de consensus doit « sélectionner à l'aveugle » l'ordre des transactions, ce qui semble empêcher de profiter des opportunités MEV lors de la phase de tri.

Mais malheureusement, que ce soit du point de vue de l'application pratique ou théorique, les pools de mémoire cryptée ne peuvent pas fournir de solution universelle au problème des MEV. Cet article expliquera les difficultés associées et explorera les directions de conception viables pour les pools de mémoire cryptée.

Fonctionnement de la mémoire tampon cryptée

De nombreuses propositions ont été faites concernant la mémoire de cryptage, mais son cadre général est le suivant :

1. L'utilisateur diffuse la transaction chiffrée.
2. Les transactions cryptées sont soumises à la chaîne (dans certaines propositions, les transactions doivent d'abord passer par un mélange aléatoire vérifiable).
3. Lorsque les blocs contenant ces transactions sont finalement confirmés, les transactions sont décryptées.
4. Exécutez ces transactions en dernier.

Il est important de noter qu'il y a un problème clé dans l'étape 3 (décryptage des transactions) : qui est responsable du décryptage ? Que se passe-t-il si le décryptage échoue ? Une idée simple serait de permettre aux utilisateurs de déchiffrer leurs propres transactions (dans ce cas, il n'est même pas nécessaire de chiffrer, il suffit de cacher l'engagement). Mais cette méthode présente des failles : un attaquant pourrait mettre en œuvre un MEV spéculatif.

Dans le MEV spéculatif, un attaquant va deviner qu'une transaction cryptographique contient une opportunité de MEV, puis il va chiffrer sa propre transaction et tenter de l'insérer à un endroit favorable (par exemple, avant ou après la transaction cible). Si les transactions sont ordonnées comme prévu, l'attaquant déchiffrera et extraira le MEV via sa propre transaction ; si ce n'est pas le cas, il refusera de déchiffrer et sa transaction ne sera pas incluse dans la blockchain finale.

Il peut être possible d'imposer des sanctions aux utilisateurs qui échouent à déchiffrer, mais la mise en œuvre de ce mécanisme est extrêmement difficile. La raison en est que : la rigueur des sanctions pour toutes les transactions cryptées doit être uniforme (après tout, il est impossible de distinguer les transactions une fois cryptées), et les sanctions doivent être suffisamment sévères pour contenir le MEV spéculatif même face à des cibles de grande valeur. Cela entraînera le blocage d'un montant considérable de fonds, et ces fonds doivent rester anonymes (pour éviter de révéler l'association entre les transactions et les utilisateurs). Plus compliqué encore, si des utilisateurs réels ne peuvent pas déchiffrer correctement en raison de vulnérabilités logicielles ou de pannes réseau, ils subiront également des pertes.

Ainsi, la plupart des solutions suggèrent que lors du cryptage des transactions, il faut s'assurer qu'elles pourront être décryptées à un moment donné dans le futur, même si l'utilisateur à l'origine de la transaction est hors ligne ou refuse de coopérer. Cet objectif peut être atteint de plusieurs manières :

Environnements d'exécution de confiance (TEE) : Les utilisateurs peuvent chiffrer les transactions avec des clés détenues par des zones de sécurité d'environnement d'exécution de confiance (TEE). Dans certaines versions de base, le TEE est uniquement utilisé pour déchiffrer les transactions après un moment spécifique (ce qui nécessite que le TEE ait une capacité de perception du temps). Des solutions plus complexes confient au TEE la tâche de déchiffrer les transactions et de construire des blocs, en triant les transactions selon des critères tels que le temps d'arrivée, les frais, etc. Par rapport à d'autres solutions de mémoire cryptée, l'avantage du TEE réside dans sa capacité à traiter directement les transactions en clair, en réduisant les informations redondantes sur la chaîne grâce à l'élimination des transactions susceptibles d'être annulées. Cependant, cette méthode présente l'inconvénient de dépendre de la confiance dans le matériel.

Partage de secrets et cryptage par seuil (Secret-sharing and threshold encryption) : Dans ce schéma, l'utilisateur chiffre la transaction avec une certaine clé, qui est détenue conjointement par un comité spécifique (généralement un sous-ensemble de validateurs). Le déchiffrement nécessite de satisfaire à certaines conditions de seuil (par exemple, deux tiers des membres du comité doivent être d'accord).

Lors de l'utilisation du décryptage par seuil, le vecteur de confiance passe du matériel à un comité. Les partisans soutiennent que, puisque la plupart des protocoles supposent déjà que les validateurs possèdent la caractéristique de "majorité honnête" dans le mécanisme de consensus, nous pouvons faire une hypothèse similaire, à savoir que la majorité des validateurs resteront honnêtes et ne déchiffreront pas les transactions à l'avance.

Cependant, il est important de noter une distinction clé : ces deux hypothèses de confiance ne sont pas la même chose. Les échecs de consensus, comme les forks de blockchain, ont une visibilité publique (appartenant à l'« hypothèse de faible confiance »), tandis que le décryptage anticipé des transactions par un comité malveillant ne laisse aucune preuve publique, cette attaque ne peut être ni détectée ni punie (appartenant à l'« hypothèse de forte confiance »). Par conséquent, bien qu'à première vue, le mécanisme de consensus et les hypothèses de sécurité des comités cryptographiques semblent cohérents, dans la pratique, la crédibilité de l'hypothèse « le comité ne conspirera pas » est beaucoup plus faible.

Verrouillage temporel et cryptage différé (Time-lock and delay encryption) : En tant qu'alternative au cryptage par seuil, le principe du cryptage différé est le suivant : l'utilisateur crypte la transaction à l'aide d'une clé publique, tandis que la clé privée correspondante est cachée dans une énigme à verrouillage temporel. Une énigme à verrouillage temporel est un problème cryptographique qui encapsule un secret, dont le contenu secret ne peut être révélé qu'après un certain temps prédéfini. Plus précisément, le processus de décryptage nécessite l'exécution répétée d'une série de calculs non parallélisables. Dans ce mécanisme, n'importe qui peut résoudre l'énigme pour obtenir la clé et déchiffrer la transaction, à condition d'effectuer une série de calculs lents (essentiellement exécutés de manière sérielle) qui prennent suffisamment de temps, garantissant que la transaction ne peut pas être déchiffrée avant sa confirmation finale. La forme la plus forte de ce primitive de cryptage est générée publiquement par la technologie de cryptage différé pour créer de telles énigmes ; cela peut également être approximé par un comité de confiance à l'aide de cryptage à verrouillage temporel, bien que dans ce cas, l'avantage par rapport au cryptage par seuil soit discutable.

Que ce soit par le biais du chiffrement différé ou par des calculs exécutés par un comité de confiance, ces types de solutions font face à de nombreux défis pratiques : tout d'abord, en raison de la dépendance inhérente au processus de calcul, il est difficile d'assurer une précision dans le temps de déchiffrement ; ensuite, ces solutions nécessitent des entités spécifiques pour faire fonctionner du matériel haute performance afin de résoudre efficacement les énigmes, bien que n'importe qui puisse assumer ce rôle, il reste flou comment inciter cette entité à participer ; enfin, dans ce type de conception, toutes les transactions diffusées seront déchiffrées, y compris celles qui n'ont jamais été finalement écrites dans un bloc. En revanche, les solutions basées sur un seuil (ou le chiffrement par témoin) pourraient ne déchiffrer que les transactions qui ont été incluses avec succès.

Chiffrement par témoin (Witness encryption) : La dernière solution cryptographique avancée utilise la technologie de « chiffrement par témoin ». En théorie, le mécanisme de chiffrement par témoin est le suivant : une fois les informations chiffrées, seules les personnes connaissant des « informations témoins » correspondant à une relation NP spécifique peuvent les déchiffrer. Par exemple, les informations peuvent être chiffrées de telle manière que seules les personnes capables de résoudre un certain puzzle de sudoku, ou pouvant fournir une préimage de hachage d'une valeur donnée, peuvent effectuer le déchiffrement.

(Note : La relation NP est la relation entre le « problème » et la « réponse pouvant être vérifiée rapidement »)

Pour toute relation NP, une logique similaire peut être réalisée par les SNARKs. On peut dire que le cryptage de témoignages consiste essentiellement à chiffrer des données d'une manière qui ne permet leur déchiffrement qu'aux entités pouvant prouver qu'elles satisfont des conditions spécifiques à l'aide de SNARK. Dans le scénario de pool de mémoire cryptée, un exemple typique de telles conditions est : les transactions ne peuvent être déchiffrées qu'après la confirmation finale du bloc.

C'est un langage théorique avec un potentiel considérable. En réalité, c'est un schéma de généralisation, où les méthodes basées sur des comités et celles basées sur des délais ne sont que des formes d'application spécifiques. Malheureusement, nous n'avons pas encore de solution cryptographique basée sur des témoins qui puisse être mise en œuvre concrètement. De plus, même si une telle solution existait, il serait difficile de dire qu'elle aurait un avantage sur les méthodes basées sur des comités dans une chaîne de preuve d'enjeu. Même si le cryptage par témoin était configuré pour se déchiffrer "uniquement lorsque les transactions sont triées dans le bloc final", un comité malveillant pourrait toujours simuler en privé le protocole de consensus pour falsifier l'état de confirmation finale d'une transaction, et utiliser cette chaîne privée comme "témoin" pour déchiffrer la transaction. À ce stade, le même comité pourrait utiliser le déchiffrement par seuil pour atteindre une sécurité équivalente, tout en étant beaucoup plus simple à mettre en œuvre.

Cependant, dans un protocole de consensus par preuve de travail, les avantages de la cryptographie des témoins sont encore plus évidents. En effet, même si le comité est entièrement malveillant, il ne peut pas miner plusieurs nouveaux blocs en secret sur la chaîne de blocs actuelle pour falsifier l'état de confirmation finale.

Défis technologiques auxquels est confronté le pool de mémoire cryptographique

De nombreux défis pratiques limitent la capacité des pools de mémoire cryptographique à prévenir le MEV. Dans l'ensemble, la confidentialité de l'information est en soi un problème difficile. Il est à noter que l'application de la technologie cryptographique dans le domaine du Web3 n'est pas largement répandue, mais des décennies de pratique dans le déploiement de la technologie cryptographique dans les réseaux (comme TLS/HTTPS) et la communication privée (de PGP à Signal, WhatsApp et autres plateformes de messagerie cryptée modernes) ont pleinement exposé les difficultés : la cryptographie, bien qu'étant un outil de protection de la confidentialité, ne peut garantir une protection absolue.

Tout d'abord, certains acteurs peuvent accéder directement aux informations en clair des transactions des utilisateurs. Dans un scénario typique, les utilisateurs ne chiffrent généralement pas leurs transactions eux-mêmes, mais délèguent cette tâche à un fournisseur de portefeuille. De cette manière, le fournisseur de portefeuille peut accéder aux transactions en clair et peut même utiliser ou vendre ces informations pour extraire des MEV. La sécurité du chiffrement dépend toujours de tous les acteurs ayant accès aux clés. La portée du contrôle des clés définit la frontière de la sécurité.

En outre, le plus grand problème réside dans les métadonnées, c'est-à-dire les données non chiffrées entourant le chargement cryptographique (transaction). Les chercheurs peuvent utiliser ces métadonnées pour déduire l'intention de la transaction et ainsi mettre en œuvre un MEV spéculatif. Il faut savoir que les chercheurs n'ont pas besoin de comprendre complètement le contenu de la transaction, ni de deviner correctement à chaque fois. Par exemple, tant qu'ils peuvent juger avec une probabilité raisonnable qu'une transaction provient d'un ordre d'achat d'une bourse décentralisée (DEX) spécifique, cela suffit pour lancer une attaque.

Nous pouvons classer les métadonnées en plusieurs catégories : l'une est constituée des problèmes classiques inhérents à la technologie cryptographique, l'autre concerne des problèmes spécifiques aux pools de mémoire cryptographique.

• Taille de la transaction : Le cryptage lui-même ne peut pas cacher la taille du texte en clair (il convient de noter que la définition formelle de la sécurité sémantique exclut explicitement le masquage de la taille du texte en clair). C'est un vecteur d'attaque courant dans la communication cryptée, un exemple typique étant que, même après cryptage, un écouteur peut toujours juger en temps réel du contenu diffusé sur Netflix en se basant sur la taille de chaque paquet de données dans le flux vidéo. Dans une mémoire tampon cryptée, certains types de transactions peuvent avoir une taille unique, ce qui peut révéler des informations.
• Temps de diffusion : La cryptographie ne peut pas non plus cacher les informations temporelles (c'est un autre vecteur d'attaque classique). Dans le contexte de Web3, certains expéditeurs (comme dans les scénarios de vente structurée) peuvent initier des transactions à intervalles fixes. Le temps de transaction peut également être associé à d'autres informations, comme l'activité des échanges externes ou des événements d'actualité. Une manière plus discrète d'exploiter les informations temporelles est l'arbitrage entre les échanges centralisés (CEX) et les échanges décentralisés (DEX) : les ordonneurs peuvent insérer des transactions créées aussi tard que possible pour exploiter les dernières informations de prix du CEX ; en même temps, les ordonneurs peuvent exclure toutes les autres transactions diffusées après un certain moment (même si elles sont cryptées), garantissant que leur transaction bénéficie d'un avantage de prix à jour.
• Adresse IP source : Les chercheurs peuvent déduire l'identité de l'expéditeur de la transaction en surveillant le réseau pair à pair et en traçant l'adresse IP source. Ce problème a été identifié dès les débuts de Bitcoin (il y a plus de dix ans). Si un expéditeur particulier présente un modèle de comportement fixe, cela est extrêmement précieux pour les chercheurs. Par exemple, en connaissant l'identité de l'expéditeur, ils peuvent relier les transactions cryptées à des transactions historiques décryptées.
• Expéditeur de la transaction et informations sur les frais / gas : Les frais de transaction sont un type de métadonnées spécifique à la mémoire cryptographique. Dans Ethereum, une transaction traditionnelle comprend l'adresse de l'expéditeur sur la chaîne (utilisée pour payer les frais), le budget maximum de gas et le coût unitaire de gas que l'expéditeur est prêt à payer. Tout comme l'adresse du réseau source, l'adresse de l'expéditeur peut être utilisée pour associer plusieurs transactions et entités réelles ; le budget de gas peut suggérer l'intention de la transaction. Par exemple, interagir avec un DEX spécifique peut nécessiter une quantité fixe de gas identifiable.

Les chercheurs complexes peuvent combiner plusieurs types de métadonnées mentionnés ci-dessus pour prédire le contenu des transactions.

Théoriquement, ces informations peuvent toutes être cachées, mais cela nécessite un coût en termes de performance et de complexité. Par exemple, remplir les transactions à une longueur standard peut cacher la taille, mais cela gaspille de la bande passante et de l'espace sur la chaîne ; ajouter un délai avant l'envoi peut cacher le temps, mais cela augmente le délai ; soumettre des transactions via des réseaux anonymes comme Tor peut cacher l'adresse IP, mais cela entraîne de nouveaux défis.

Les métadonnées les plus difficiles à cacher sont les informations sur les frais de transaction. Les données de frais de cryptographie posent une série de problèmes aux constructeurs de blocs : tout d'abord, le problème des informations inutiles ; si les données de frais de transaction sont cryptées, n'importe qui peut diffuser des transactions cryptées au format incorrect. Ces transactions peuvent être triées, mais ne peuvent pas être payées, et une fois décryptées, elles ne peuvent pas être exécutées sans qu'aucun responsable ne puisse être identifié. Cela pourrait peut-être être résolu par des SNARKs, c'est-à-dire prouvant que le format de transaction est correct et que les fonds sont suffisants, mais cela augmenterait considérablement les coûts.

Deuxièmement, il y a le problème de l'efficacité de la construction des blocs et des enchères de frais. Les constructeurs dépendent des informations sur les frais pour créer des blocs maximisant le profit et déterminer le prix du marché actuel des ressources en chaîne. Les données sur les frais en cryptomonnaie perturbent ce processus. Une solution consiste à établir des frais fixes pour chaque bloc, mais cela est économiquement inefficace et pourrait également donner naissance à un marché secondaire pour le regroupement des transactions, ce qui va à l'encontre de l'intention de conception des pools de mémoire en cryptomonnaie. Une autre solution consiste à réaliser des enchères de frais via un calcul multipartite sécurisé ou du matériel de confiance, mais ces deux méthodes sont extrêmement coûteuses.

Enfin, un pool de mémoire cryptographique sécurisé augmentera les coûts du système de plusieurs manières : le cryptage augmentera la latence, la charge de calcul et la consommation de bande passante de la chaîne ; il n'est pas encore clair comment cela s'intègre avec des objectifs futurs importants tels que le sharding ou l'exécution parallèle ; cela pourrait également introduire de nouveaux points de défaillance pour la vivacité (liveness) (comme le comité de décryptage dans les schémas de seuil, les solveurs de fonctions de délai) ; en même temps, la complexité de la conception et de la mise en œuvre augmentera également de manière significative.

De nombreux problèmes liés aux pools de mémoire cryptographique sont similaires aux défis auxquels sont confrontées les blockchains visant à garantir la confidentialité des transactions (comme Zcash, Monero). S'il y a un aspect positif, c'est que résoudre tous les défis de la technologie cryptographique dans l'atténuation de la MEV permettra également de lever les obstacles à la confidentialité des transactions.

Les défis économiques auxquels est confronté le pool de mémoire cryptographique

Enfin, le pool de mémoire cryptographique fait également face à des défis économiques. Contrairement aux défis techniques, qui peuvent être atténués progressivement par un investissement d'ingénierie suffisant, ces défis économiques constituent des limitations fondamentales et sont extrêmement difficiles à résoudre.

Le problème central de l'MEV provient de l'asymétrie d'information entre les créateurs de transactions (utilisateurs) et les exploitants d'opportunités MEV (chercheurs et constructeurs de blocs). Les utilisateurs ne savent généralement pas combien de valeur extractible est contenue dans leurs transactions, de sorte que même en présence d'un pool de mémoire cryptographique parfait, ils peuvent être incités à divulguer des clés de déchiffrement en échange d'une récompense inférieure à la valeur réelle de l'MEV, un phénomène que l'on peut qualifier de « déchiffrement incitatif ».

Il n'est pas difficile d'imaginer ce genre de scénario, car des mécanismes similaires comme MEV Share existent déjà dans la réalité. MEV Share est un mécanisme d'enchères sur le flux des ordres qui permet aux utilisateurs de soumettre sélectivement des informations de transaction à un pool. Les chercheurs obtiennent par la compétition le droit d'exploiter les opportunités MEV associées à ces transactions. Le soumissionnaire gagnant, après avoir extrait le MEV, restituera une partie des bénéfices (c'est-à-dire le montant de l'enchère ou un certain pourcentage de celui-ci) aux utilisateurs.

Ce modèle peut s'adapter directement aux pools de mémoire cryptée : les utilisateurs doivent divulguer la clé de déchiffrement (ou certaines informations) pour participer. Mais la plupart des utilisateurs ne réalisent pas le coût d'opportunité de participer à de tels mécanismes, ils ne voient que le retour immédiat et sont donc prêts à divulguer des informations. Il existe également des cas similaires dans la finance traditionnelle : par exemple, la plateforme de trading sans commission Robinhood, dont le modèle économique repose sur la vente des flux d'ordres des utilisateurs à des tiers via le "paiement pour le flux d'ordres".

Un autre scénario possible est le suivant : de grands constructeurs pourraient contraindre les utilisateurs à divulguer le contenu des transactions (ou des informations connexes) sous prétexte de conformité. L'anticonformisme est un sujet important et controversé dans le domaine de Web3, mais si de grands validateurs ou constructeurs sont légalement tenus (comme les directives de l'OFAC aux États-Unis) d'appliquer une liste de vérification, ils pourraient refuser de traiter toute transaction cryptographique. Techniquement, les utilisateurs pourraient éventuellement prouver, par le biais de preuves à divulgation nulle de connaissance, que leurs transactions cryptographiques sont conformes aux exigences de conformité, mais cela entraînerait des coûts et une complexité supplémentaires. Même si la blockchain présente une forte résistance à la censure (garantissant que les transactions cryptographiques doivent être incluses), les constructeurs pourraient toujours donner la priorité aux transactions en clair connues en tête de bloc, reléguant les transactions cryptées à la fin. Ainsi, ceux qui ont besoin de garantir la priorité d'exécution des transactions pourraient finalement être contraints de divulguer le contenu aux constructeurs.

Autres défis en matière d'efficacité

Les pools de mémoire cryptée augmentent les coûts du système de plusieurs manières évidentes. Les utilisateurs doivent chiffrer les transactions, et le système doit également les déchiffrer d'une manière ou d'une autre, ce qui augmente le coût de calcul et peut également augmenter le volume des transactions. Comme mentionné précédemment, le traitement des métadonnées exacerbe encore ces coûts. Cependant, il existe également des coûts d'efficacité qui ne sont pas aussi évidents. Dans le domaine financier, si les prix peuvent refléter toutes les informations disponibles, le marché est considéré comme efficace ; tandis que les retards et l'asymétrie de l'information peuvent rendre le marché inefficace. C'est exactement le résultat inévitable des pools de mémoire cryptée.

Cette inefficacité entraîne une conséquence directe : l'augmentation de l'incertitude des prix, qui est le produit direct des retards supplémentaires introduits par les pools de mémoire cryptographique. Par conséquent, les transactions échouant en raison du dépassement de la tolérance au glissement des prix pourraient augmenter, ce qui gaspillerait de l'espace sur la chaîne.

De même, cette incertitude des prix pourrait également donner naissance à des transactions MEV spéculatives, qui tentent de tirer profit de l'arbitrage sur la chaîne. Il convient de noter que les pools de mémoire cryptographique pourraient rendre ces opportunités plus courantes : en raison des délais d'exécution, l'état actuel des échanges décentralisés (DEX) devient plus flou, ce qui pourrait conduire à une baisse de l'efficacité du marché et à des écarts de prix entre différentes plateformes de trading. Ce type de transactions MEV spéculatives peut également gaspiller de l'espace de bloc, car une fois qu'aucune opportunité d'arbitrage n'est découverte, elles ont tendance à cesser leur exécution.

Résumé

L'objectif de cet article est de dresser un bilan des défis auxquels sont confrontées les pools de mémoire cryptographique, afin que les gens puissent orienter leurs efforts vers le développement d'autres solutions, mais les pools de mémoire cryptographique pourraient néanmoins devenir une partie des solutions de gouvernance MEV.

Une approche viable est la conception hybride : une partie des transactions est réalisée par un "tri aveugle" via un pool de mémoire cryptée, tandis qu'une autre partie utilise d'autres schémas de tri. Pour des types spécifiques de transactions (par exemple, les ordres d'achat et de vente de grands acteurs du marché, qui ont la capacité de chiffrer ou de remplir soigneusement les transactions et qui sont prêts à payer des coûts plus élevés pour éviter le MEV), la conception hybride peut être un choix approprié. Pour les transactions hautement sensibles (comme les transactions de correction des contrats de sécurité présentant des vulnérabilités), cette conception a également un sens pratique.

Cependant, en raison des limitations techniques, de la complexité élevée des projets et des coûts de performance, le pool de mémoire cryptée est peu susceptible de devenir la "solution universelle MEV" tant attendue. La communauté doit développer d'autres solutions, y compris les enchères MEV, des mécanismes de défense au niveau des applications et la réduction du temps de confirmation finale. Le MEV restera un défi pendant un certain temps à l'avenir et nécessitera des recherches approfondies pour trouver un équilibre entre les différentes solutions afin de faire face à ses impacts négatifs.