Auteur | Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Compilation | Saoirse, Foresight News
Dans la blockchain, il est possible de gagner de l'argent en décidant quelles transactions sont incluses dans un bloc, lesquelles sont exclues, ou en ajustant l'ordre des transactions. La valeur maximale qui peut être extraite de cette manière est appelée « valeur maximale extractible », abrégée en MEV. Le MEV existe dans la plupart des blockchains et a toujours été un sujet de préoccupation et de discussion dans l'industrie.
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 ? L'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 tirer profit des opportunités MEV pendant 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 MEV. Cet article expliquera les difficultés associées et explorera les directions de conception viables pour les pools de mémoire cryptée.
Le fonctionnement de la mémoire de pool cryptographique
De nombreuses propositions ont été faites concernant le pool de mémoire cryptographique, mais son cadre général est le suivant :
L'utilisateur diffuse des transactions cryptées.
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).
Une fois que les blocs contenant ces transactions sont finalement confirmés, les transactions sont déchiffrées.
Exécutez enfin ces transactions.
Il convient de noter qu'il existe un problème clé à l'étape 3 (décryptage des transactions) : qui est responsable du décryptage ? Que faire si le décryptage échoue ? Une idée simple serait de laisser les utilisateurs déchiffrer eux-mêmes leurs 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 crypter 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 organisées dans l'ordre prévu, l'attaquant décrypta et extraira le MEV par le biais de sa propre transaction ; si cela ne se passe pas comme prévu, il refusera de déchiffrer et sa transaction ne sera pas incluse dans la blockchain finale.
Il pourrait ê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 : l'intensité 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 dissuader même les MEV spéculatifs face à des cibles de haute valeur. Cela entraînerait le blocage d'une grande quantité de fonds, et ces fonds devraient rester anonymes (pour éviter la divulgation de l'association entre les transactions et les utilisateurs). Plus délicat encore, si des utilisateurs réels ne peuvent pas déchiffrer normalement en raison de failles de programme 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 initiateur 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 des transactions avec des clés détenues dans la zone de sécurité des environnements d'exécution de confiance (TEE). Dans certaines versions de base, le TEE est uniquement utilisé pour déchiffrer les transactions après un certain moment (ce qui nécessite que le TEE ait une capacité de perception du temps). Des solutions plus complexes confient au TEE la responsabilité 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 et les frais. 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, réduisant ainsi les informations redondantes sur la chaîne en filtrant les transactions susceptibles d'être annulées. Cependant, cette méthode présente le inconvénient de dépendre de la fiabilité du matériel.
Partage de secret et cryptage par seuil (Secret-sharing and threshold encryption) : dans ce schéma, l'utilisateur crypte 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écryptage doit satisfaire à certaines conditions de seuil (par exemple, deux tiers des membres du comité doivent donner leur accord).
Lors de l'utilisation du déchiffrement par seuil, le support de confiance passe du matériel à un comité. Les partisans estiment que, puisque la plupart des protocoles supposent par défaut que les validateurs possèdent la caractéristique de « majorité honnête » dans le mécanisme de consensus, nous pouvons également faire une hypothèse similaire, à savoir que la majorité des validateurs restera honnête et ne déchiffrera 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 tels que les forks de blockchain ont une visibilité publique (appartenant à l'« hypothèse de faible confiance »), tandis que le déchiffrement anticipé des transactions par un comité malveillant en privé ne laisse aucune preuve publique, cette attaque ne peut ni être détectée ni punie (appartenant à l'« hypothèse de forte confiance »). Ainsi, bien que, à première vue, le mécanisme de consensus et l'hypothèse de sécurité du comité cryptographique semblent cohérents, en pratique, la crédibilité de l'hypothèse « le comité ne conspirera pas » est beaucoup plus faible.
Verrouillage temporel et cryptage de retard (Time-lock and delay encryption) : en tant qu'alternative à la cryptographie par seuil, le principe du cryptage de retard est le suivant : l'utilisateur chiffre la transaction avec une certaine clé publique, tandis que la clé privée correspondante est cachée dans une énigme de verrouillage temporel. L'énigme de verrouillage temporel est une énigme cryptographique qui encapsule un secret, dont le contenu secret ne peut être révélé qu'après un temps prédéfini ; plus précisément, le processus de déchiffrement nécessite l'exécution répétée d'une série de calculs non parallélisables. Dans ce mécanisme, quiconque 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 en série) dont la durée est suffisamment longue, garantissant que la transaction ne peut pas être déchiffrée avant sa confirmation finale. La forme la plus forte de ce primitive cryptographique est générée publiquement à l'aide de la technologie de cryptage de retard ; cela peut également être approximé par un comité de confiance utilisant le cryptage à verrouillage temporel, bien que, dans ce cas, ses avantages par rapport à la cryptographie par seuil soient discutables.
Que ce soit par le biais du cryptage différé ou par le calcul exécuté par un comité de confiance, ces types de solutions sont confrontés à de nombreux défis pratiques : tout d'abord, comme le délai dépend essentiellement du processus de calcul, il est difficile d'assurer la précision du temps de décryptage ; ensuite, ces solutions doivent compter sur des entités spécifiques pour exécuter du matériel de haute performance afin de résoudre efficacement les énigmes, bien que quiconque puisse assumer ce rôle, il n'est pas encore clair comment inciter cette entité à participer ; enfin, dans ce type de conception, toutes les transactions diffusées seront décryptées, y compris celles qui n'ont jamais été finalement écrites dans un bloc. En revanche, les solutions basées sur des seuils (ou cryptage par témoin) peuvent potentiellement ne déchiffrer que les transactions qui ont été incluses avec succès.
Cryptographie par témoin (Witness encryption) : La dernière et la plus avancée des solutions cryptographiques utilise la technologie de « cryptographie par témoin ». Théoriquement, le mécanisme de la cryptographie par témoin est le suivant : les informations sont chiffrées de sorte que seules les personnes connaissant les « informations témoins » correspondant à une relation NP spécifique peuvent les déchiffrer. Par exemple, les informations peuvent être chiffrées de manière à ce que seules les personnes capables de résoudre une certaine énigme de sudoku, ou pouvant fournir une pré-image de hachage spécifique, puissent accomplir 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 des preuves est essentiellement le processus de cryptage des données de manière à ce que seules les entités pouvant prouver qu'elles satisfont à des conditions particulières via SNARK puissent déchiffrer ces données. Dans le contexte d'un pool de mémoire cryptée, un exemple typique de ces conditions est que les transactions ne peuvent être déchiffrées qu'après la confirmation définitive du bloc.
C'est un langage théorique d'une grande potentiel. En fait, c'est un schéma de généralité, où les méthodes basées sur les comités et celles basées sur le délai ne sont que ses applications concrètes. Malheureusement, nous n'avons pas encore de schéma cryptographique basé sur des témoins qui soit réellement réalisable. De plus, même s'il existait un tel schéma, il serait difficile de dire s'il serait plus avantageux que la méthode basée sur les comités dans une chaîne de preuve de participation. Même en réglant la cryptographie des témoins pour « déchiffrer uniquement lorsque les transactions sont triées dans un bloc définitivement validé », un comité malveillant pourrait toujours simuler un protocole de consensus en privé pour falsifier l'état de confirmation finale des transactions, et utiliser cette chaîne privée comme « témoin » pour déchiffrer les transactions. À ce moment, un même comité pourrait utiliser le déchiffrement par seuil pour atteindre un niveau de sécurité équivalent, et l'opération serait beaucoup plus simple.
Cependant, dans le protocole de consensus par preuve de travail, les avantages de la cryptographie des témoins sont encore plus évidents. Car même si le comité est entièrement malveillant, il ne peut pas miner plusieurs nouveaux blocs en secret sur la tête de la blockchain actuelle pour falsifier l'état de confirmation finale.
Les défis techniques auxquels est confronté le pool de mémoire cryptographique
Plusieurs défis pratiques limitent la capacité des pools de mémoire cryptographique à prévenir le MEV. En général, la confidentialité de l'information est en soi un problème difficile. Il convient de noter que l'application de la technologie cryptographique dans le domaine du Web3 n'est pas largement répandue, mais des décennies de pratiques de déploiement de la technologie cryptographique dans les réseaux (comme TLS/HTTPS) et les communications privées (de PGP à Signal, WhatsApp et autres plateformes de messagerie cryptée modernes) ont pleinement exposé les difficultés : bien que la cryptographie soit un outil de protection de la confidentialité, elle ne peut pas garantir une protection absolue.
Tout d'abord, certains acteurs peuvent accéder directement aux informations textuelles des transactions des utilisateurs. Dans un scénario typique, les utilisateurs ne chiffrent généralement pas leurs transactions eux-mêmes, mais confient cette tâche à un fournisseur de services de portefeuille. De cette manière, le fournisseur de services de portefeuille peut accéder au texte brut des transactions et pourrait même utiliser ou vendre ces informations pour extraire le MEV. La sécurité du chiffrement dépend toujours de tous les acteurs qui ont accès aux clés. La portée du contrôle des clés détermine la frontière de la sécurité.
En dehors de cela, le plus grand problème réside dans les métadonnées, c'est-à-dire les données non chiffrées entourant la charge utile cryptographique (transaction). Les chercheurs peuvent utiliser ces métadonnées pour déduire l'intention de la transaction, ce qui leur permet de mettre en œuvre des MEV spéculatifs. Il est important de noter 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'un échange décentralisé (DEX) spécifique, cela suffit pour lancer une attaque.
Nous pouvons classer les métadonnées en plusieurs catégories : d'une part, il y a les problèmes classiques inhérents à la technologie cryptographique, et d'autre part, il y a les problèmes spécifiques aux pools de mémoire cryptographique.
Taille de la transaction : La cryptographie elle-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 les communications cryptées, un cas typique étant que, même après cryptage, un espion peut toujours déterminer en temps réel le contenu diffusé sur Netflix par 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 des tailles uniques, révélant ainsi des informations.
Heure de diffusion : La cryptographie ne peut également pas cacher les informations temporelles (c'est un autre vecteur d'attaque classique). Dans le scénario Web3, certains expéditeurs (comme dans le cas de ventes structurées) peuvent initier des transactions à intervalles réguliers. Le temps de la transaction peut également être associé à d'autres informations, telles que l'activité des bourses 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) : le triant peut insérer des transactions créées aussi tard que possible pour exploiter les dernières informations de prix des CEX ; en même temps, le triant peut exclure toutes les autres transactions diffusées après un certain point dans le temps (même si elles sont cryptées), garantissant que sa transaction bénéficie seule de l'avantage de prix le plus récent.
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 a un modèle de comportement fixe, cela est d'une grande valeur pour les chercheurs. Par exemple, en connaissant l'identité de l'expéditeur, il est possible de lier les transactions cryptées aux transactions historiques déjà décryptées.
Informations sur l'expéditeur de la transaction et les frais / gas : Les frais de transaction sont un type de métadonnées spécifique à la mémoire des cryptomonnaies. Dans Ethereum, une transaction traditionnelle comprend l'adresse de l'expéditeur sur la chaîne (pour payer les frais), le budget gas maximum et le coût unitaire de gas que l'expéditeur est prêt à payer. Comme l'adresse du réseau source, l'adresse de l'expéditeur peut être utilisée pour associer plusieurs transactions et des entités réelles ; le budget gas peut alors 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 a 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 retard ; 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 sur les frais cryptographiques posent une série de problèmes aux constructeurs de blocs : tout d'abord, le problème des informations indésirables, si les données sur les frais de transaction sont cryptées, n'importe qui peut diffuser une transaction cryptée mal formatée, ces transactions peuvent être triées mais ne peuvent pas payer de frais, une fois décryptées, elles ne peuvent pas être exécutées et personne ne peut être tenu responsable. Cela pourrait peut-être être résolu par des SNARKs, c'est-à-dire prouver que le format de la transaction est correct et que les fonds sont suffisants, mais cela augmenterait considérablement les coûts.
Ensuite, il y a le problème de l'efficacité de la construction de 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 sur la chaîne. Les données sur les frais cryptographiques compromettent ce processus. Une solution consiste à fixer des frais fixes pour chaque bloc, mais cela est économiquement inefficace et pourrait également donner naissance à un marché secondaire pour le regroupement des transactions, contredisant ainsi l'intention de conception de la mémoire tampon cryptographique. Une autre solution consiste à organiser 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, une mémoire tampon cryptée sécurisée augmentera les coûts système de plusieurs manières : le cryptage augmentera la latence de la chaîne, la charge de calcul et la consommation de bande passante ; il n'est pas encore clair comment cela s'articulera 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 les comités de décryptage dans les schémas à 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 des pools de mémoire cryptographique sont similaires aux défis auxquels sont confrontées les blockchains visant à garantir la confidentialité des transactions (comme Zcash et 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 l'MEV éliminera également les obstacles à la confidentialité des transactions.
Les défis économiques auxquels sont confrontés les pools 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 progressivement atténués par un investissement d'ingénierie suffisant, ces défis économiques constituent des limitations fondamentales, et leur résolution est extrêmement difficile.
Le problème central de l'MEV découle de l'asymétrie d'information entre les créateurs de transactions (utilisateurs) et les mineurs d'opportunités MEV (chercheurs et constructeurs de blocs). Les utilisateurs ne sont généralement pas conscients de la valeur extractible contenue dans leurs transactions. Ainsi, même en présence d'une mémoire interne cryptographique parfaite, ils peuvent être amenés à divulguer une clé 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 appeler "décryptage incitatif".
Ce scénario n'est pas difficile à imaginer, car des mécanismes similaires comme MEV Share existent déjà dans la réalité. MEV Share est un mécanisme d'enchères de flux d'ordres qui permet aux utilisateurs de soumettre sélectivement des informations de transaction dans un pool, les chercheurs obtenant par la compétition le droit d'exploiter les opportunités MEV de cette transaction. Le soumissionnaire gagnant, après avoir extrait le MEV, remboursera une partie des bénéfices (c'est-à-dire le montant de l'enchère ou un certain pourcentage de celui-ci) à l'utilisateur.
Ce modèle peut s'adapter directement aux pools de mémoire cryptographique : les utilisateurs doivent divulguer une clé de déchiffrement (ou des informations partielles) 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 heureux de divulguer des informations. On trouve également des cas similaires dans la finance traditionnelle : par exemple, la plateforme de trading sans commission Robinhood, dont le modèle de profit consiste à vendre le flux d'ordres des utilisateurs à des tiers par le biais du "paiement pour le flux d'ordres".
Un autre scénario possible est que de grands constructeurs, sous prétexte de censure, forcent les utilisateurs à divulguer le contenu des transactions (ou des informations connexes). La résistance à la censure est un sujet important et controversé dans le domaine du Web3, mais si de grands validateurs ou constructeurs sont contraints par la loi (comme les règlements du Bureau de contrôle des avoirs étrangers OFAC des États-Unis) d'appliquer une liste de censure, ils peuvent refuser de traiter toute transaction crypto. D'un point de vue technique, les utilisateurs pourraient éventuellement prouver, via des preuves à divulgation nulle de connaissance, que leurs transactions crypto respectent les exigences de censure, mais cela entraînerait des coûts et une complexité supplémentaires. Même si la blockchain possède une forte résistance à la censure (assurant que les transactions crypto sont inévitablement incluses), les constructeurs pourraient toujours prioriser les transactions en clair connues en tête de bloc, tandis que les transactions cryptées seraient placées à la fin. Par conséquent, ceux qui ont besoin de garantir la priorité d'exécution des transactions pourraient finalement être contraints de divulguer le contenu aux constructeurs.
D'autres défis en matière d'efficacité
La mémoire tampon cryptée augmentera les coûts système de manière évidente et variée. 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 la taille des transactions. Comme mentionné précédemment, le traitement des métadonnées aggravera 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 conduisent à une inefficacité du marché. C'est le résultat inévitable de la mémoire tampon 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 le pool de mémoire cryptographique. Par conséquent, les transactions échouant en raison d'une tolérance au glissement de prix dépassée pourraient augmenter, gaspillant ainsi l'espace sur la chaîne.
De même, cette incertitude des prix peut également engendrer des transactions MEV spéculatives, qui tentent de tirer profit de l'arbitrage sur la chaîne. Il est à noter que la mémoire des transactions en cryptomonnaie pourrait 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 peut entraîner une baisse de l'efficacité du marché et des différences de prix entre différentes plateformes de trading. De telles transactions MEV spéculatives peuvent également gaspiller de l'espace dans les blocs, car une fois qu'aucune opportunité d'arbitrage n'est trouvée, elles ont tendance à cesser leur exécution.
Résumé
L'objectif de cet article est de passer en revue les défis auxquels sont confrontées les mémoires tampon cryptographiques, afin que les gens puissent concentrer leurs efforts sur le développement d'autres solutions, mais les mémoires tampon cryptographiques peuvent néanmoins faire partie des solutions de gouvernance MEV.
Une approche viable est la conception hybride : une partie des transactions utilise un « tri aveugle » grâce à des pools de mémoire cryptée, tandis qu'une autre partie adopte d'autres schémas de tri. Pour des types spécifiques de transactions (comme 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 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 visant des contrats sécurisés présentant des vulnérabilités), cette conception est également d'une grande pertinence.
Cependant, en raison des limitations techniques, de la complexité élevée des travaux et des coûts de performance, la mémoire tampon cryptographique est peu susceptible de devenir la "solution universelle MEV" tant attendue. La communauté doit développer d'autres solutions, y compris des enchères MEV, des mécanismes de défense au niveau des applications et la réduction des temps de confirmation finale. Le MEV restera un défi pendant un certain temps, nécessitant des recherches approfondies pour trouver un équilibre entre les différentes solutions afin de faire face à ses effets négatifs.
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.
a16z : Pourquoi le pool de mémoire de chiffrement est-il difficile à devenir le remède universel contre le MEV ?
Auteur | Pranav Garimidi, Joseph Bonneau, Lioba Heimbach, a16z
Compilation | Saoirse, Foresight News
Dans la blockchain, il est possible de gagner de l'argent en décidant quelles transactions sont incluses dans un bloc, lesquelles sont exclues, ou en ajustant l'ordre des transactions. La valeur maximale qui peut être extraite de cette manière est appelée « valeur maximale extractible », abrégée en MEV. Le MEV existe dans la plupart des blockchains et a toujours été un sujet de préoccupation et de discussion dans l'industrie.
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 ? L'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 tirer profit des opportunités MEV pendant 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 MEV. Cet article expliquera les difficultés associées et explorera les directions de conception viables pour les pools de mémoire cryptée.
Le fonctionnement de la mémoire de pool cryptographique
De nombreuses propositions ont été faites concernant le pool de mémoire cryptographique, mais son cadre général est le suivant :
L'utilisateur diffuse des transactions cryptées.
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).
Une fois que les blocs contenant ces transactions sont finalement confirmés, les transactions sont déchiffrées.
Exécutez enfin ces transactions.
Il convient de noter qu'il existe un problème clé à l'étape 3 (décryptage des transactions) : qui est responsable du décryptage ? Que faire si le décryptage échoue ? Une idée simple serait de laisser les utilisateurs déchiffrer eux-mêmes leurs 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 crypter 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 organisées dans l'ordre prévu, l'attaquant décrypta et extraira le MEV par le biais de sa propre transaction ; si cela ne se passe pas comme prévu, il refusera de déchiffrer et sa transaction ne sera pas incluse dans la blockchain finale.
Il pourrait ê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 : l'intensité 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 dissuader même les MEV spéculatifs face à des cibles de haute valeur. Cela entraînerait le blocage d'une grande quantité de fonds, et ces fonds devraient rester anonymes (pour éviter la divulgation de l'association entre les transactions et les utilisateurs). Plus délicat encore, si des utilisateurs réels ne peuvent pas déchiffrer normalement en raison de failles de programme 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 initiateur 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 des transactions avec des clés détenues dans la zone de sécurité des environnements d'exécution de confiance (TEE). Dans certaines versions de base, le TEE est uniquement utilisé pour déchiffrer les transactions après un certain moment (ce qui nécessite que le TEE ait une capacité de perception du temps). Des solutions plus complexes confient au TEE la responsabilité 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 et les frais. 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, réduisant ainsi les informations redondantes sur la chaîne en filtrant les transactions susceptibles d'être annulées. Cependant, cette méthode présente le inconvénient de dépendre de la fiabilité du matériel.
Partage de secret et cryptage par seuil (Secret-sharing and threshold encryption) : dans ce schéma, l'utilisateur crypte 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écryptage doit satisfaire à certaines conditions de seuil (par exemple, deux tiers des membres du comité doivent donner leur accord).
Lors de l'utilisation du déchiffrement par seuil, le support de confiance passe du matériel à un comité. Les partisans estiment que, puisque la plupart des protocoles supposent par défaut que les validateurs possèdent la caractéristique de « majorité honnête » dans le mécanisme de consensus, nous pouvons également faire une hypothèse similaire, à savoir que la majorité des validateurs restera honnête et ne déchiffrera 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 tels que les forks de blockchain ont une visibilité publique (appartenant à l'« hypothèse de faible confiance »), tandis que le déchiffrement anticipé des transactions par un comité malveillant en privé ne laisse aucune preuve publique, cette attaque ne peut ni être détectée ni punie (appartenant à l'« hypothèse de forte confiance »). Ainsi, bien que, à première vue, le mécanisme de consensus et l'hypothèse de sécurité du comité cryptographique semblent cohérents, en pratique, la crédibilité de l'hypothèse « le comité ne conspirera pas » est beaucoup plus faible.
Verrouillage temporel et cryptage de retard (Time-lock and delay encryption) : en tant qu'alternative à la cryptographie par seuil, le principe du cryptage de retard est le suivant : l'utilisateur chiffre la transaction avec une certaine clé publique, tandis que la clé privée correspondante est cachée dans une énigme de verrouillage temporel. L'énigme de verrouillage temporel est une énigme cryptographique qui encapsule un secret, dont le contenu secret ne peut être révélé qu'après un temps prédéfini ; plus précisément, le processus de déchiffrement nécessite l'exécution répétée d'une série de calculs non parallélisables. Dans ce mécanisme, quiconque 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 en série) dont la durée est suffisamment longue, garantissant que la transaction ne peut pas être déchiffrée avant sa confirmation finale. La forme la plus forte de ce primitive cryptographique est générée publiquement à l'aide de la technologie de cryptage de retard ; cela peut également être approximé par un comité de confiance utilisant le cryptage à verrouillage temporel, bien que, dans ce cas, ses avantages par rapport à la cryptographie par seuil soient discutables.
Que ce soit par le biais du cryptage différé ou par le calcul exécuté par un comité de confiance, ces types de solutions sont confrontés à de nombreux défis pratiques : tout d'abord, comme le délai dépend essentiellement du processus de calcul, il est difficile d'assurer la précision du temps de décryptage ; ensuite, ces solutions doivent compter sur des entités spécifiques pour exécuter du matériel de haute performance afin de résoudre efficacement les énigmes, bien que quiconque puisse assumer ce rôle, il n'est pas encore clair comment inciter cette entité à participer ; enfin, dans ce type de conception, toutes les transactions diffusées seront décryptées, y compris celles qui n'ont jamais été finalement écrites dans un bloc. En revanche, les solutions basées sur des seuils (ou cryptage par témoin) peuvent potentiellement ne déchiffrer que les transactions qui ont été incluses avec succès.
Cryptographie par témoin (Witness encryption) : La dernière et la plus avancée des solutions cryptographiques utilise la technologie de « cryptographie par témoin ». Théoriquement, le mécanisme de la cryptographie par témoin est le suivant : les informations sont chiffrées de sorte que seules les personnes connaissant les « informations témoins » correspondant à une relation NP spécifique peuvent les déchiffrer. Par exemple, les informations peuvent être chiffrées de manière à ce que seules les personnes capables de résoudre une certaine énigme de sudoku, ou pouvant fournir une pré-image de hachage spécifique, puissent accomplir 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 des preuves est essentiellement le processus de cryptage des données de manière à ce que seules les entités pouvant prouver qu'elles satisfont à des conditions particulières via SNARK puissent déchiffrer ces données. Dans le contexte d'un pool de mémoire cryptée, un exemple typique de ces conditions est que les transactions ne peuvent être déchiffrées qu'après la confirmation définitive du bloc.
C'est un langage théorique d'une grande potentiel. En fait, c'est un schéma de généralité, où les méthodes basées sur les comités et celles basées sur le délai ne sont que ses applications concrètes. Malheureusement, nous n'avons pas encore de schéma cryptographique basé sur des témoins qui soit réellement réalisable. De plus, même s'il existait un tel schéma, il serait difficile de dire s'il serait plus avantageux que la méthode basée sur les comités dans une chaîne de preuve de participation. Même en réglant la cryptographie des témoins pour « déchiffrer uniquement lorsque les transactions sont triées dans un bloc définitivement validé », un comité malveillant pourrait toujours simuler un protocole de consensus en privé pour falsifier l'état de confirmation finale des transactions, et utiliser cette chaîne privée comme « témoin » pour déchiffrer les transactions. À ce moment, un même comité pourrait utiliser le déchiffrement par seuil pour atteindre un niveau de sécurité équivalent, et l'opération serait beaucoup plus simple.
Cependant, dans le protocole de consensus par preuve de travail, les avantages de la cryptographie des témoins sont encore plus évidents. Car même si le comité est entièrement malveillant, il ne peut pas miner plusieurs nouveaux blocs en secret sur la tête de la blockchain actuelle pour falsifier l'état de confirmation finale.
Les défis techniques auxquels est confronté le pool de mémoire cryptographique
Plusieurs défis pratiques limitent la capacité des pools de mémoire cryptographique à prévenir le MEV. En général, la confidentialité de l'information est en soi un problème difficile. Il convient de noter que l'application de la technologie cryptographique dans le domaine du Web3 n'est pas largement répandue, mais des décennies de pratiques de déploiement de la technologie cryptographique dans les réseaux (comme TLS/HTTPS) et les communications privées (de PGP à Signal, WhatsApp et autres plateformes de messagerie cryptée modernes) ont pleinement exposé les difficultés : bien que la cryptographie soit un outil de protection de la confidentialité, elle ne peut pas garantir une protection absolue.
Tout d'abord, certains acteurs peuvent accéder directement aux informations textuelles des transactions des utilisateurs. Dans un scénario typique, les utilisateurs ne chiffrent généralement pas leurs transactions eux-mêmes, mais confient cette tâche à un fournisseur de services de portefeuille. De cette manière, le fournisseur de services de portefeuille peut accéder au texte brut des transactions et pourrait même utiliser ou vendre ces informations pour extraire le MEV. La sécurité du chiffrement dépend toujours de tous les acteurs qui ont accès aux clés. La portée du contrôle des clés détermine la frontière de la sécurité.
En dehors de cela, le plus grand problème réside dans les métadonnées, c'est-à-dire les données non chiffrées entourant la charge utile cryptographique (transaction). Les chercheurs peuvent utiliser ces métadonnées pour déduire l'intention de la transaction, ce qui leur permet de mettre en œuvre des MEV spéculatifs. Il est important de noter 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'un échange décentralisé (DEX) spécifique, cela suffit pour lancer une attaque.
Nous pouvons classer les métadonnées en plusieurs catégories : d'une part, il y a les problèmes classiques inhérents à la technologie cryptographique, et d'autre part, il y a les problèmes spécifiques aux pools de mémoire cryptographique.
Taille de la transaction : La cryptographie elle-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 les communications cryptées, un cas typique étant que, même après cryptage, un espion peut toujours déterminer en temps réel le contenu diffusé sur Netflix par 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 des tailles uniques, révélant ainsi des informations.
Heure de diffusion : La cryptographie ne peut également pas cacher les informations temporelles (c'est un autre vecteur d'attaque classique). Dans le scénario Web3, certains expéditeurs (comme dans le cas de ventes structurées) peuvent initier des transactions à intervalles réguliers. Le temps de la transaction peut également être associé à d'autres informations, telles que l'activité des bourses 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) : le triant peut insérer des transactions créées aussi tard que possible pour exploiter les dernières informations de prix des CEX ; en même temps, le triant peut exclure toutes les autres transactions diffusées après un certain point dans le temps (même si elles sont cryptées), garantissant que sa transaction bénéficie seule de l'avantage de prix le plus récent.
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 a un modèle de comportement fixe, cela est d'une grande valeur pour les chercheurs. Par exemple, en connaissant l'identité de l'expéditeur, il est possible de lier les transactions cryptées aux transactions historiques déjà décryptées.
Informations sur l'expéditeur de la transaction et les frais / gas : Les frais de transaction sont un type de métadonnées spécifique à la mémoire des cryptomonnaies. Dans Ethereum, une transaction traditionnelle comprend l'adresse de l'expéditeur sur la chaîne (pour payer les frais), le budget gas maximum et le coût unitaire de gas que l'expéditeur est prêt à payer. Comme l'adresse du réseau source, l'adresse de l'expéditeur peut être utilisée pour associer plusieurs transactions et des entités réelles ; le budget gas peut alors 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 a 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 retard ; 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 sur les frais cryptographiques posent une série de problèmes aux constructeurs de blocs : tout d'abord, le problème des informations indésirables, si les données sur les frais de transaction sont cryptées, n'importe qui peut diffuser une transaction cryptée mal formatée, ces transactions peuvent être triées mais ne peuvent pas payer de frais, une fois décryptées, elles ne peuvent pas être exécutées et personne ne peut être tenu responsable. Cela pourrait peut-être être résolu par des SNARKs, c'est-à-dire prouver que le format de la transaction est correct et que les fonds sont suffisants, mais cela augmenterait considérablement les coûts.
Ensuite, il y a le problème de l'efficacité de la construction de 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 sur la chaîne. Les données sur les frais cryptographiques compromettent ce processus. Une solution consiste à fixer des frais fixes pour chaque bloc, mais cela est économiquement inefficace et pourrait également donner naissance à un marché secondaire pour le regroupement des transactions, contredisant ainsi l'intention de conception de la mémoire tampon cryptographique. Une autre solution consiste à organiser 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, une mémoire tampon cryptée sécurisée augmentera les coûts système de plusieurs manières : le cryptage augmentera la latence de la chaîne, la charge de calcul et la consommation de bande passante ; il n'est pas encore clair comment cela s'articulera 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 les comités de décryptage dans les schémas à 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 des pools de mémoire cryptographique sont similaires aux défis auxquels sont confrontées les blockchains visant à garantir la confidentialité des transactions (comme Zcash et 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 l'MEV éliminera également les obstacles à la confidentialité des transactions.
Les défis économiques auxquels sont confrontés les pools 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 progressivement atténués par un investissement d'ingénierie suffisant, ces défis économiques constituent des limitations fondamentales, et leur résolution est extrêmement difficile.
Le problème central de l'MEV découle de l'asymétrie d'information entre les créateurs de transactions (utilisateurs) et les mineurs d'opportunités MEV (chercheurs et constructeurs de blocs). Les utilisateurs ne sont généralement pas conscients de la valeur extractible contenue dans leurs transactions. Ainsi, même en présence d'une mémoire interne cryptographique parfaite, ils peuvent être amenés à divulguer une clé 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 appeler "décryptage incitatif".
Ce scénario n'est pas difficile à imaginer, car des mécanismes similaires comme MEV Share existent déjà dans la réalité. MEV Share est un mécanisme d'enchères de flux d'ordres qui permet aux utilisateurs de soumettre sélectivement des informations de transaction dans un pool, les chercheurs obtenant par la compétition le droit d'exploiter les opportunités MEV de cette transaction. Le soumissionnaire gagnant, après avoir extrait le MEV, remboursera une partie des bénéfices (c'est-à-dire le montant de l'enchère ou un certain pourcentage de celui-ci) à l'utilisateur.
Ce modèle peut s'adapter directement aux pools de mémoire cryptographique : les utilisateurs doivent divulguer une clé de déchiffrement (ou des informations partielles) 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 heureux de divulguer des informations. On trouve également des cas similaires dans la finance traditionnelle : par exemple, la plateforme de trading sans commission Robinhood, dont le modèle de profit consiste à vendre le flux d'ordres des utilisateurs à des tiers par le biais du "paiement pour le flux d'ordres".
Un autre scénario possible est que de grands constructeurs, sous prétexte de censure, forcent les utilisateurs à divulguer le contenu des transactions (ou des informations connexes). La résistance à la censure est un sujet important et controversé dans le domaine du Web3, mais si de grands validateurs ou constructeurs sont contraints par la loi (comme les règlements du Bureau de contrôle des avoirs étrangers OFAC des États-Unis) d'appliquer une liste de censure, ils peuvent refuser de traiter toute transaction crypto. D'un point de vue technique, les utilisateurs pourraient éventuellement prouver, via des preuves à divulgation nulle de connaissance, que leurs transactions crypto respectent les exigences de censure, mais cela entraînerait des coûts et une complexité supplémentaires. Même si la blockchain possède une forte résistance à la censure (assurant que les transactions crypto sont inévitablement incluses), les constructeurs pourraient toujours prioriser les transactions en clair connues en tête de bloc, tandis que les transactions cryptées seraient placées à la fin. Par conséquent, ceux qui ont besoin de garantir la priorité d'exécution des transactions pourraient finalement être contraints de divulguer le contenu aux constructeurs.
D'autres défis en matière d'efficacité
La mémoire tampon cryptée augmentera les coûts système de manière évidente et variée. 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 la taille des transactions. Comme mentionné précédemment, le traitement des métadonnées aggravera 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 conduisent à une inefficacité du marché. C'est le résultat inévitable de la mémoire tampon 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 le pool de mémoire cryptographique. Par conséquent, les transactions échouant en raison d'une tolérance au glissement de prix dépassée pourraient augmenter, gaspillant ainsi l'espace sur la chaîne.
De même, cette incertitude des prix peut également engendrer des transactions MEV spéculatives, qui tentent de tirer profit de l'arbitrage sur la chaîne. Il est à noter que la mémoire des transactions en cryptomonnaie pourrait 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 peut entraîner une baisse de l'efficacité du marché et des différences de prix entre différentes plateformes de trading. De telles transactions MEV spéculatives peuvent également gaspiller de l'espace dans les blocs, car une fois qu'aucune opportunité d'arbitrage n'est trouvée, elles ont tendance à cesser leur exécution.
Résumé
L'objectif de cet article est de passer en revue les défis auxquels sont confrontées les mémoires tampon cryptographiques, afin que les gens puissent concentrer leurs efforts sur le développement d'autres solutions, mais les mémoires tampon cryptographiques peuvent néanmoins faire partie des solutions de gouvernance MEV.
Une approche viable est la conception hybride : une partie des transactions utilise un « tri aveugle » grâce à des pools de mémoire cryptée, tandis qu'une autre partie adopte d'autres schémas de tri. Pour des types spécifiques de transactions (comme 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 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 visant des contrats sécurisés présentant des vulnérabilités), cette conception est également d'une grande pertinence.
Cependant, en raison des limitations techniques, de la complexité élevée des travaux et des coûts de performance, la mémoire tampon cryptographique est peu susceptible de devenir la "solution universelle MEV" tant attendue. La communauté doit développer d'autres solutions, y compris des enchères MEV, des mécanismes de défense au niveau des applications et la réduction des temps de confirmation finale. Le MEV restera un défi pendant un certain temps, nécessitant des recherches approfondies pour trouver un équilibre entre les différentes solutions afin de faire face à ses effets négatifs.