Sur les limites des mempools chiffrés

La valeur qui peut être extraite en incluant, excluant ou réorganisant des transactions dans un bloc est connue sous le nom de "valeur extractible maximale, ou MEV. MEV est courant sur la plupart des blockchains et a été un sujet d'intérêt et de discussion généralisé dans la communauté.

Note : Cet article de blog suppose une familiarité de base avec MEV. Certains lecteurs pourraient souhaiter commencer par lire notre Explication de l'MEV.

De nombreux chercheurs, observant la situation du MEV, ont posé une question évidente : La cryptographie peut-elle résoudre le problème ? Une approche consiste en un mempool crypté, où les utilisateurs diffusent des transactions cryptées qui ne sont révélées qu'après avoir été ordonnées. Par conséquent, un protocole de consensus devrait s'engager à un ordre de transaction à l'aveugle, semblant empêcher la possibilité de tirer parti des opportunités de MEV pendant le processus d'ordonnancement.

Malheureusement, pour des raisons pratiques et théoriques, nous ne voyons pas les mempools chiffrés comme une solution universelle au MEV. Nous décrivons les difficultés et explorons comment les mempools chiffrés pourraient être conçus.

Comment fonctionnent les mempools encryptés

Il y a eu de nombreuses propositions pour des mempools chiffrés, mais le cadre général pour les mempools chiffrés est le suivant :

1. Les utilisateurs diffusent leurs transactions cryptées.
2. Les transactions cryptées sont engagées sur la chaîne (dans certaines propositions après avoir été mélangé de manière prouvable aléatoirement)
3. Après que le bloc engagé est finalisé, les transactions sont décryptées.
4. Enfin, les transactions sont exécutées.

Notez que l'étape 3 (décryptage des transactions) pose un défi important : qui déchiffre, et que se passe-t-il si le décryptage ne se fait pas ? Une solution naïve serait de dire que les utilisateurs déchiffrent eux-mêmes leurs transactions (dans ce cas, il ne serait même pas nécessaire d'avoir un chiffrement, mais on pourrait simplement cacher les engagements). Cependant, cette approche est vulnérable : un attaquant peut effectuerMEV spéculatif.

Avec l'MEV spéculatif, un attaquant essaie de deviner qu'une certaine transaction cryptée génère de l'MEV. Ils cryptent leurs propres transactions qui, espérons-le, apparaîtront à un endroit opportun (par exemple, juste avant ou après une transaction cible). Si la transaction est séquencée dans l'ordre espéré, l'attaquant déchiffre et sa transaction extrait l'MEV. Sinon, ils choisissent de ne pas déchiffrer et leur transaction n'est pas incluse dans la chaîne finale.

Peut-être que les utilisateurs pourraient faire face à une certaine pénalité pour ne pas réussir à déchiffrer, mais cela est délicat à mettre en œuvre. La pénalité devrait être la même pour toutes les transactions chiffrées (puisqu'elles sont chiffrées et donc indiscernables), mais aussi suffisamment élevée pour décourager l'MEV spéculatif même contre des cibles de grande valeur. Cela nécessiterait de bloquer beaucoup de capital, qui devrait être anonyme (pour éviter de divulguer des informations sur les transactions postées par quels utilisateurs). Et cela finirait par coûter cher aux utilisateurs honnêtes en cas de bug ou de défaillance du réseau qui empêche leur tentative légitime de déchiffrer.

Ainsi, la plupart des propositions suggèrent que les transactions soient chiffrées de manière à garantir que le déchiffrement pourra être réalisé à un moment donné dans le futur — même si l'utilisateur qui publie se déconnecte ou ne coopère pas. Cela peut être réalisé de plusieurs manières :

TEEs : Les utilisateurs peuvent chiffrer leurs transactions avec une clé détenue par un Environnement d'Exécution de Confiance (TEE) enclave. Dans certaines versions simples, le TEE est uniquement utilisé pour déchiffrer les transactions après une certaine date limite (ce qui nécessite une notion de temps au sein du TEE). Des approches plus avancées utilisent le TEE pour déchiffrer les transactions et construire le bloc, en les ordonnant en fonction de certains critères tels que les heures d'arrivée ou les frais. Un avantage des TEE par rapport à d'autres approches de mempool chiffré est leur capacité à fonctionner sur des transactions en texte clair, réduisant ainsi le spam on-chain en filtrant les transactions qui seraient annulées. Cependant, cette méthode nécessite une confiance dans le matériel.

Partage de secrets et cryptage par seuil : Avec cette approche, les utilisateurs cryptent les transactions avec une clé qui est partagée par un certain comité, généralement un sous-ensemble de validateurs. Un seuil (par exemple, deux tiers du comité) est requis pour le décryptage.

L'approche la plus simple utilise une nouvelle clé de décryptage partagée à chaque tour (par exemple, chaque bloc ou époque sur Ethereum), que le comité reconstruit et publie après que les transactions ont été ordonnées dans un bloc finalisé. Cette approche peut utiliser un partage secret simple. L'inconvénient est qu'elle révèle toutes les transactions du mempool, même celles qui n'ont pas été incluses dans un bloc. Cette approche nécessite également une nouvelle génération de clé distribuée (DKG) à chaque tour.

Une meilleure approche pour la confidentialité consiste à déchiffrer uniquement les transactions qui ont été réellement incluses. Cela peut être réalisé en utilisant le déchiffrement par seuil. Cette approche permet également d'amortir le coût des protocoles DKG en utilisant la même clé pour plusieurs blocs, la commission déchiffrant les transactions après qu'elles ont été ordonnées dans un bloc finalisé. Un défi est que la commission doit faire beaucoup plus de travail. Naïvement, le travail de la commission est linéaire par rapport au nombre de transactions à déchiffrer, bien querécenttravailsuggère le déchiffrement par seuil par lots, ce qui peut améliorer cela de manière significative.

Avec le déchiffrement par seuil, la confiance passe d'un matériel à un comité. L'affirmation est que, puisque la plupart des protocoles supposent déjà une majorité honnête concernant les validateurs pour le protocole de consensus, nous pouvons faire une hypothèse similaire selon laquelle une majorité de validateurs est honnête et ne déchiffrera pas les transactions prématurément. Une note de prudence est toutefois de mise : ce ne sont pas les mêmes hypothèses de confiance. Les échecs de consensus comme le fork de la chaîne sont visibles publiquement (appelés une hypothèse de confiance faible), tandis qu'un comité malveillant déchiffrant des transactions en privé générera aucune preuve publique et donc une telle attaque ne peut être détectée ou pénalisée (une hypothèse de confiance forte). Ainsi, bien que, de l'extérieur, les hypothèses de sécurité pour le consensus et un comité de déchiffrement puissent sembler identiques, des considérations pratiques rendent l'hypothèse selon laquelle un comité ne colludera pas plus précaire.

Le verrouillage temporel et le chiffrement par délai : Une alternative au chiffrement par seuil se présente sous la forme du chiffrement par délai. Les utilisateurs chiffrent leurs transactions avec une clé publique dont la clé secrète est cachée dans une énigme verrouillée dans le temps. Une énigme verrouillée dans le temps est une énigme cryptographique qui encapsule un secret, qui ne peut être révélé qu'après qu'un certain temps prédéterminé se soit écoulé – plus précisément, l'énigme peut être déchiffrée en effectuant de manière répétée un certain calcul non parallélisable. Dans ce cas, cette énigme peut être ouverte par quiconque pour récupérer la clé et déchiffrer les transactions, mais seulement après un calcul lent (inévitablement séquentiel) qui est conçu pour prendre suffisamment de temps pour que les transactions ne puissent pas être déchiffrées avant d'avoir été finalisées. La version la plus forte de ce principe utilise chiffrement de retardpour générer publiquement un tel puzzle. Il peut également être approximé en utilisant un comité de confiance pour calculer le puzzle via le chiffrement par verrouillage temporel, bien qu'à ce stade, les avantages par rapport au chiffrement par seuil soient discutables.

Que ce soit par le biais du chiffrement de retard ou de l'informatique par un comité de confiance, il existe un certain nombre de défis pratiques. Tout d'abord, il est plus difficile d'assurer un timing précis du déchiffrement, car le retard est de nature computationnelle. Deuxièmement, ces schémas reposent sur une entité utilisant du matériel sophistiqué pour résoudre les énigmes de manière efficace. Bien que n'importe qui puisse jouer ce rôle, il n'est pas clair comment inciter cette partie. Enfin, dans ces conceptions, toutes les transactions diffusées seront déchiffrées, y compris celles qui n'ont jamais été finalisées dans un bloc. Les solutions basées sur des seuils (ou le chiffrement de témoin) pourraient potentiellement ne déchiffrer que les transactions qui sont effectivement incluses.

Chiffrement par témoin. Enfin, l'approche cryptographique la plus avancée utilise un outil appelé chiffrement par témoin. Théoriquement, le cryptage par témoin permet de chiffrer des informations pour quiconque connaît le témoin d'une relation NP spécifique. Par exemple, on pourrait chiffrer de manière à ce que quiconque possède la solution d'un certain puzzle Sudoku, ou quiconque possède une préimage de hachage d'une certaine valeur, puisse déchiffrer.

Les SNARKs sont également possibles pour toute relation NP. On peut penser à l'encryption de témoins comme à l'encryptage de données pour quiconque peut calculer un SNARK prouvant une condition souhaitée. Pour les mempools encryptés, un exemple d'une telle condition serait que les transactions ne peuvent être décryptées que lorsqu'un bloc a été finalisé.

C'est un très puissant primitive théorique. En fait, c'est une généralisation pour laquelle les approches basées sur des comités et les approches basées sur des délais sont des cas spécifiques. Malheureusement, nous n'avons pas de constructions pratiques de l'encryption basée sur des témoins. De plus, même si nous en avions, il n'est pas clair en quoi cela constitue une amélioration par rapport à une approche basée sur un comité pour les chaînes de preuve d'enjeu. Même si l'encryption par témoin est mise en place de sorte que les transactions ne puissent être décryptées que lorsqu'elles sont ordonnées dans un bloc finalisé, un comité malveillant peut toujours simuler en privé le protocole de consensus de sorte que la transaction soit finalisée, puis utiliser cette chaîne privée comme témoin pour déchiffrer les transactions. À ce stade, utiliser le déchiffrement par seuil par le même comité offre une sécurité équivalente et est beaucoup plus simple.

Le chiffrement de témoin offre un avantage plus décisif dans les protocoles de consensus par preuve de travail, car même un comité entièrement malveillant ne peut pas miner en privé plusieurs nouveaux blocs au-dessus de la tête actuelle pour simuler la finalité.

Défis techniques pour les mempools encryptés

Plusieurs défis pratiques importants limitent la capacité des mempools chiffrés à prévenir le MEV. En général, garder des informations confidentielles est difficile. Fait intéressant, le chiffrement est un outil rarement utilisé dans l'espace web3. Mais nous avons des décennies d'expérience pratique qui mettent en évidence les défis liés au déploiement du chiffrement sur le web (TLS/HTTPS) et pour la communication privée (de PGP aux plateformes de messagerie chiffrée modernes comme Signal ou Whatsapp). Bien que le chiffrement soit un outil pour préserver la confidentialité, il ne la garantit pas.

Tout d'abord, il peut y avoir des parties ayant un accès direct au texte en clair de la transaction d'un utilisateur. Dans des cas typiques, les utilisateurs peuvent ne pas chiffrer leur propre transaction mais en confier cette tâche à leur fournisseur de portefeuille. Par conséquent, le fournisseur de portefeuille a accès à la transaction en clair et pourrait utiliser ou vendre cette information pour extraire le MEV. Le chiffrement n'est jamais plus fort que l'ensemble des parties ayant accès à la clé.

Au-delà de cela, le plus grand problème est les métadonnées, c'est-à-dire les données entourant la charge utile chiffrée (transaction), qui ne sont pas chiffrées. Les chercheurs peuvent utiliser ces métadonnées pour deviner l'intention d'une transaction et ensuite tenter un MEV spéculatif. N'oubliez pas que les chercheurs n'ont pas besoin de comprendre pleinement une transaction, ni d'avoir raison à chaque fois. Il suffit qu'ils sachent, par exemple, qu'avec une probabilité raisonnable, une transaction représente un ordre d'achat d'un DEX spécifique.

Nous pouvons considérer plusieurs types de métadonnées, dont certaines sont des défis classiques liés au chiffrement et d'autres qui sont uniques aux mempools chiffrés.

• Taille de la transaction : Le chiffrement en lui-même ne cache pas la taille du texte en clair chiffré. (Il y a, de manière notoire, une exception spécifique faite dans les définitions formelles de la sécurité sémantique pour exclure le fait de cacher la taille du texte en clair chiffré.) C'est un vecteur d'attaque classique sur la communication chiffrée. (Dans un exemple célèbre, même avec le chiffrement, un écouteur clandestinpeut déterminer quelle vidéo est diffusé en temps réel sur Netflix à partir de la taille de chaque paquet dans le flux vidéo.) Dans le contexte du mempool crypté, certains types de transactions peuvent avoir une taille spécifique qui divulgue des informations.

• Heure de diffusion : Le cryptage ne cache pas non plus les informations de synchronisation (un autrevecteur d'attaque classique). Dans le contexte web3, certains expéditeurs — par exemple, dans la vente structurée — pourraient effectuer des transactions à intervalles réguliers. Le moment des transactions pourrait également être corrélé à d'autres informations, telles que l'activité sur des échanges externes ou des événements d'actualité. Une manière plus subtile d'exploiter les informations de timing est l'arbitrage CEX/DEX. Un séquenceur peut bénéficier de l'insertion d'une transaction créée aussi tard que possible, profitant d'informations plus récentes sur les prix CEX. Le même séquenceur pourrait exclure toutes les autres transactions (même si cryptées) diffusées après un certain moment, garantissant que sa transaction seule ait l'avantage des informations de prix les plus à jour.

• Adresse IP d'origine : Les chercheurs pourraient déduire l'identité de l'expéditeur d'une transaction en surveillant le réseau pair-à-pair et en observant l'adresse IP d'origine. Ce problème était en fait identifié il y a plus de dix ans dans les premiers jours de Bitcoin. Cela peut être utile aux chercheurs si des expéditeurs spécifiques ont des modèles spécifiques — par exemple, connaître l'expéditeur pourrait permettre de lier une transaction chiffrée à des transactions antérieures qui ont déjà été déchiffrées.

• Informations sur l'expéditeur de la transaction et les frais/de gaz : Enfin, les frais de transaction représentent un type de métadonnées spécifique aux mempools chiffrés. Dans Ethereum, les transactions incluent classiquement une adresse d'expéditeur (onchain), qui est utilisée pour payer les frais, ainsi qu'un budget maximal de gaz et un frais par unité de gaz que l'expéditeur est prêt à payer. L'adresse de l'expéditeur, tout comme l'adresse du réseau d'origine, peut être utilisée pour lier les transactions entre elles et à des entités du monde réel. Le budget de gaz peut être utilisé pour estimer ce que la transaction vise à accomplir. Par exemple, interagir avec un DEX spécifique pourrait nécessiter un montant spécifique de gaz qui est identifiable.

Les chercheurs sophistiqués pourraient utiliser n'importe quelle combinaison des types de métadonnées ci-dessus pour prédire le contenu d'une transaction.

Toutes ces informations pourraient potentiellement être cachées, mais au prix de performances et de complexité. Par exemple, le rembourrage des transactions jusqu'à une limite standard cache la taille des transactions, mais cela gaspille de la bande passante et de l'espace sur la chaîne. Ajouter des délais avant d'envoyer des messages cache le temps de transaction, mais nuit à la latence. Soumettre des transactions via un réseau d'anonymat comme Tor pourrait cacher l'adresse IP de l'expéditeur, mais cela a ses propres défis.

Les données de frais de transaction sont les métadonnées les plus difficiles à cacher. Chiffrer ces données crée un certain nombre de défis pour le constructeur. Le premier problème est le spam. Si les données de paiement des frais de transaction sont chiffrées, alors n'importe qui peut diffuser des transactions chiffrées malformées qui seront ordonnées mais qui n'auront pas la capacité de payer les frais. Ainsi, après déchiffrement, elles ne pourront pas être exécutées, mais aucune partie ne pourra être pénalisée. Cela pourrait éventuellement être résolu avec des SNARKs qui prouvent qu'une transaction est bien formée et financée, mais cela augmenterait considérablement la surcharge.

Le deuxième problème est la construction efficace de blocs et les enchères de frais. Les bâtisseurs utilisent les frais pour construire le bloc le plus rentable et établir le prix du marché actuel pour les ressources onchain. Chiffrer ces données perturbe ce processus. Cela pourrait être résolu en établissant des frais fixes dans chaque bloc, mais cela est économiquement inefficace et pourrait encourager des marchés secondaires pour l'inclusion des transactions qui compromettraient l'objectif d'avoir un mempool chiffré. Réaliser une enchère de frais en utilisant un calcul multipartite sécurisé ou du matériel de confiance est possible, mais ces deux étapes sont coûteuses.

Enfin, les mempools sécurisés et chiffrés imposent une surcharge au système de plusieurs manières. Le chiffrement ajoute de la latence, des surcharges computationnelles et de bande passante à la chaîne. Comment le combiner avec le support pour le sharding ou l'exécution parallèle — qui sont des objectifs futurs importants — est loin d'être évident. Cela pourrait ajouter des points de défaillance supplémentaires pour la vivacité (par exemple, le comité de déchiffrement pour les solutions de seuil ou le solveur de fonction de délai). Et cela ajoute certainement à la complexité de conception et d'implémentation.

De nombreux problèmes des mempools cryptés sont partagés par les blockchains qui visent elles-mêmes à garantir la confidentialité des transactions (par exemple, Zcash, Monero). S'il y a un aspect positif, c'est que résoudre tous les défis de l'encryption pour l'atténuation de MEV permettrait, en conséquence, d'ouvrir la voie à la confidentialité des transactions.

Défis économiques pour les mempools encryptés

Enfin, les mempools cryptés font face à des défis économiques. Contrairement aux défis techniques, qui pourraient potentiellement être atténués avec suffisamment d'efforts d'ingénierie, ceux-ci sont des limitations fondamentales qui semblent difficiles à résoudre.

Le problème de base de l'MEV résulte de l'asymétrie d'information entre les utilisateurs créant des transactions et les chercheurs et constructeurs trouvant des opportunités d'MEV. Les utilisateurs ne savent généralement pas combien d'MEV peut être extrait de leurs transactions. En conséquence, même avec un mempool crypté parfait, les utilisateurs pourraient être incités à abandonner leurs clés de déchiffrement en échange d'un paiement des constructeurs qui est inférieur à la valeur extraite. Nous pouvons appeler cela le déchiffrement incitatif.

Il n'est pas difficile d'imaginer à quoi cela ressemblerait, car une version de cela, appelée MEV Share, existe aujourd'hui. MEV Share est une enchère de flux d'ordres qui permet aux utilisateurs de soumettre sélectivement des informations sur leurs transactions à un pool où les chercheurs rivalisent pour avoir la chance d'exploiter l'opportunité MEV présentée par la transaction. Le chercheur avec l'enchère gagnante extrait le MEV et rembourse une partie de son profit (c'est-à-dire l'enchère ou une fraction de l'enchère) à l'utilisateur.

Ce modèle pourrait être immédiatement adapté dans un espace de mempool crypté, exigeant des utilisateurs qu'ils révèlent leurs clés de déchiffrement (ou peut-être juste quelques informations partielles) pour participer. Mais la plupart des utilisateurs ne comprendront pas le coût d'opportunité de participer à un tel schéma, ne voyant que les récompenses qui leur reviennent et étant heureux de renoncer à leurs informations. Il existe également des exemples issus de la finance traditionnelle (par exemple, des services de trading sans frais comme Robinhood) qui réalisent des profits en vendant le flux d'ordres de leurs utilisateurs à des tiers dans un soi-disant "paiement pour le flux de commandes” modèle commercial.

D'autres scénarios possibles incluent de grands constructeurs forçant les utilisateurs à révéler leurs transactions (ou certaines informations les concernant) pour des raisons de censure. La résilience à la censure est un sujet important et controversé au sein du web3, mais si de grands proposeurs et/ou constructeurs sont légalement obligés d'appliquer une liste de censure (par exemple, par OFAC), ils peuvent refuser de séquencer toute transaction chiffrée. Il pourrait être possible de résoudre ce problème techniquement, si les utilisateurs peuvent produire une preuve à divulgation nulle de connaissance que leur transaction chiffrée est conforme à la liste de censure, mais cela ajoutera également des coûts et de la complexité. Même si la chaîne dispose d'une forte résistance à la censure, où les transactions chiffrées sont garanties d'être incluses, les constructeurs de blocs pourraient tout de même privilégier les transactions qu'ils connaissent en clair en haut du bloc et reléguer toutes les transactions chiffrées au bas du bloc. Ainsi, les transactions qui désirent certaines garanties d'exécution pourraient être forcées de révéler leur contenu aux constructeurs de toute façon.

Autres défis d'efficacité

Les mempools encryptés ajoutent des frais généraux au système de plusieurs manières évidentes. Les utilisateurs doivent chiffrer les transactions et le système doit d'une manière ou d'une autre les déchiffrer. Cela entraîne un coût computationnel et augmente probablement la taille des transactions. Comme discuté ci-dessus, le traitement des métadonnées peut aggraver ces frais généraux. Cependant, certains autres coûts d'efficacité sont moins évidents. En finance, un marché est considéré comme efficient si le prix reflète toutes les informations disponibles, et les inefficacités proviennent de délais et d'asymétries d'information - conséquences naturelles des mempools encryptés.

L'une des conséquences de ces inefficacités est l'incertitude accrue des prix, résultant du délai supplémentaire que les mempools chiffrés introduisent. Ainsi, le nombre d'échecs de transactions dus au dépassement de la tolérance de glissement des prix est susceptible d'augmenter et de gaspiller de l'espace sur la chaîne.

De même, cette incertitude des prix pourrait également mener à des transactions MEV spéculatives qui tentent de tirer profit de l'arbitrage onchain. Il est important de noter que ces opportunités pourraient être plus répandues avec des mempools encryptés, car l'incertitude accrue autour de l'état actuel des DEX, à la lumière de l'exécution retardée, est susceptible de produire des marchés moins efficaces avec des écarts de prix entre les plateformes. Ces types de transactions MEV spéculatives gaspilleraient également de l'espace de bloc car elles avorteront souvent si aucune de ces opportunités n'est trouvée.

Bien que notre objectif ici ait été de décrire les défis des mempools chiffrés, afin que les gens puissent se concentrer sur la construction et la résolution de problèmes d'autres manières, ils peuvent néanmoins faire partie de la solution au MEV.

Une solution possible est celle des conceptions hybrides, où certaines transactions sont ordonnées de manière aveugle via un mempool crypté et d'autres sont ordonnées via une autre solution. Pour certains types de transactions — par exemple, les ordres d'achat/vente de grands participants du marché qui peuvent les crypter/les remplir avec soin et sont prêts à payer plus pour éviter l'MEV — les conceptions hybrides peuvent être la bonne solution. Ces conceptions pourraient également avoir du sens pour certaines transactions très sensibles, telles que les corrections de bugs d'un contrat de sécurité présentant une vulnérabilité.

Cependant, en raison de leurs limitations technologiques, ainsi que de la complexité d'ingénierie significative et des surcoûts de performance, les mempools cryptés sont peu susceptibles d'être la solution miracle au MEV qu'ils semblent parfois être. La communauté devra développer autres solutions, y compris les enchères MEV, les défenses au niveau de l'application et la minimisation du temps de finalité. Le MEV sera un défi pendant un certain temps, et une enquête approfondie est nécessaire pour trouver le bon équilibre des solutions pour gérer ses inconvénients.

Pranav Garimidi est un associé de recherche chez a16z Crypto. Il fait des recherches sur les problèmes de conception de mécanismes et de théorie des jeux algorithmiques en rapport avec les systèmes blockchain. Il se concentre particulièrement sur la façon dont les incitations interagissent à travers la pile blockchain. Avant a16z, Pranav était étudiant à l'Université de Columbia où il a obtenu un diplôme en informatique.

Joseph Bonneau est Professeur Associé au Département d'Informatique de l'Institut Courant de l'Université de New York, et conseiller technique pour a16z crypto. Ses recherches se concentrent sur la cryptographie appliquée et la sécurité blockchain. Il a enseigné des cours de cryptomonnaie à l'Université de Melbourne, à NYU, à Stanford et à Princeton, et a obtenu un doctorat en informatique de l'Université de Cambridge ainsi que des diplômes BS/MS de Stanford.

Lioba Heimbach est un étudiant en doctorat de quatrième année conseillé par le Prof. Dr. Roger Wattenhofer dans le Informatique Distribuée (Disco) groupe à l'ETH Zurich. Ses recherches se concentrent sur les protocoles de blockchain avec un accent sur la finance décentralisée (DeFi). En particulier, elle se concentre sur la création d'un écosystème blockchain et DeFi accessible, décentralisé, équitable et efficace. Elle a été stagiaire en recherche chez a16z crypto pendant l'été 2024.

Les opinions exprimées ici sont celles des personnes individuelles de AH Capital Management, L.L.C. (“a16z”) citées et ne sont pas les opinions de a16z ou de ses affiliés. Certaines informations contenues ici ont été obtenues auprès de sources tierces, y compris des entreprises du portefeuille des fonds gérés par a16z. Bien qu'elles proviennent de sources considérées comme fiables, a16z n'a pas vérifié indépendamment ces informations et ne fait aucune représentation quant à l'exactitude actuelle ou durable des informations ou à leur pertinence pour une situation donnée. De plus, ce contenu peut inclure des publicités de tiers ; a16z n'a pas examiné ces publicités et n'approuve aucun contenu publicitaire qui y est contenu.

Ce contenu est fourni à des fins d'information uniquement et ne doit pas être considéré comme des conseils juridiques, commerciaux, d'investissement ou fiscaux. Vous devriez consulter vos propres conseillers à ce sujet. Les références à des titres ou actifs numériques sont uniquement à des fins illustratives et ne constituent pas une recommandation d'investissement ou une offre de services de conseil en investissement. De plus, ce contenu n'est pas destiné ni destiné à être utilisé par des investisseurs ou des investisseurs potentiels, et ne peut en aucun cas être pris en compte lors de la décision d'investir dans un fonds géré par a16z. (Une offre d'investissement dans un fonds a16z ne sera faite que par le mémorandum de placement privé, l'accord de souscription et d'autres documents pertinents de tout fonds et doit être lu dans leur intégralité.) Tous les investissements ou sociétés de portefeuille mentionnés, référencés ou décrits ne sont pas représentatifs de tous les investissements dans les véhicules gérés par a16z, et il n'y a aucune assurance que les investissements seront rentables ou que d'autres investissements réalisés à l'avenir auront des caractéristiques ou des résultats similaires. Une liste des investissements réalisés par les fonds gérés par Andreessen Horowitz (à l'exclusion des investissements pour lesquels l'émetteur n'a pas donné la permission à a16z de divulguer publiquement ainsi que des investissements non annoncés dans des actifs numériques négociés publiquement) est disponible àhttps://a16z.com/investments/.

Le contenu ne parle qu'à la date indiquée. Toute projection, estimation, prévision, objectif, perspective et/ou opinion exprimée dans ces documents est sujette à changement sans préavis et peut différer ou être contraire aux opinions exprimées par d'autres. Veuillez consulter https://a16z.com/disclosures pour des informations importantes supplémentaires.

Avertissement :

1. Cet article est reproduit de [ a16zcrypto]. Tous les droits d'auteur appartiennent à l'auteur original [Pranav GarimidiJoseph Bonneau ety Lioba Heimbach]. Si vous avez des objections à cette réimpression, veuillez contacter le Gate Learnéquipe, et ils s'en occuperont rapidement.
2. Avertissement de responsabilité : Les vues et opinions exprimées dans cet article ne sont que celles de l'auteur et ne constituent pas un conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.