a16z Crypto dernière recherche : Quelle est la clé de l'adoption à grande échelle de la DeFi ?

Auteur : PGarimidi, jneu_net, @MaxResnic

Rédaction : Jiahuan, ChainCatcher

La blockchain peut aujourd’hui affirmer de façon crédible qu’elle possède les capacités nécessaires pour rivaliser avec les infrastructures financières existantes. Les systèmes de production actuels peuvent traiter des dizaines de milliers de transactions par seconde, et une augmentation d’un ordre de grandeur est à venir. Cependant, au-delà du simple débit brut, les applications financières ont besoin de prévisibilité. Qu’il s’agisse d’un achat/vente, d’une enchère, ou d’une levée d’option, le fonctionnement normal d’un système financier exige une réponse déterminée : à quel moment cette transaction sera-t-elle exécutée ? Si la transaction fait face à des retards imprévisibles (qu’ils soient malveillants ou accidentels), de nombreuses applications deviennent inutilisables.

Pour que les applications financières on-chain soient compétitives, la blockchain doit fournir une garantie de paquetage à court terme : si une transaction valide est soumise au réseau, elle sera assurée d’être empaquetée le plus rapidement possible. Par exemple, considérons un carnet d’ordres on-chain. Un carnet d’ordres efficace nécessite que les teneurs de marché fournissent en continu de la liquidité en maintenant des ordres d’achat et de vente sur le registre.

Le défi clé auquel font face les teneurs de marché est le suivant : d’un côté, réduire au maximum l’écart acheteur-vendeur, et de l’autre, éviter le risque de « sélection adverse » causé par un écart de prix par rapport au marché. Pour cela, les teneurs de marché doivent continuellement mettre à jour leurs ordres afin de refléter l’état du monde réel. Par exemple, si une annonce de la Fed fait bondir brusquement le prix d’un actif, le teneur de marché doit réagir immédiatement et mettre à jour ses ordres avec le nouveau prix. Dans ce cas, si la transaction de mise à jour des ordres ne se confirme pas immédiatement, le teneur de marché subira une perte : les arbitragistes exécutent ses ordres avec le prix devenu obsolète. Le teneur de marché doit ensuite élargir davantage l’écart acheteur-vendeur pour réduire son exposition à ce type d’événements, ce qui, à son tour, diminue la compétitivité des places de marché on-chain.

Le paquetage prévisible des transactions offre aux teneurs de marché une garantie solide : ils peuvent réagir rapidement aux événements off-chain et maintenir l’efficacité du marché on-chain.

Qu’avons-nous, et de quoi avons-nous besoin ?

Aujourd’hui, les blockchains existantes ne fournissent qu’une garantie de finalité robuste, généralement valable dans une fenêtre de quelques secondes. Même si ces garanties suffisent pour des applications comme les paiements, elles sont trop faibles pour soutenir les grandes applications financières où les participants au marché doivent réagir en temps réel aux informations.

Prenons l’exemple du carnet d’ordres ci-dessus : pour un teneur de marché, si la transaction d’un arbitragiste peut être incluse dans un bloc plus tôt, alors la garantie qu’il sera empaqueté « dans les quelques secondes à venir » n’a aucune signification. Sans une garantie de paquetage forte, le teneur de marché doit gérer le risque accru de sélection adverse en élargissant l’écart et en offrant aux utilisateurs des prix moins favorables. Cela réduit fortement l’attrait des échanges on-chain par rapport à d’autres places de marché offrant des garanties plus fortes.

Pour que la blockchain réalise véritablement sa vision de modernisation de l’infrastructure du marché des capitaux, les bâtisseurs doivent résoudre ces problèmes afin que des applications de grande valeur comme les carnets d’ordres puissent prospérer.

Pourquoi est-ce si difficile d’obtenir de la prévisibilité ?

Renforcer la garantie de paquetage de la blockchain existante pour prendre en charge ces cas d’usage est un défi. Certains protocoles actuels peuvent s’appuyer sur un nœud capable, à n’importe quel moment donné, de décider quelles transactions seront empaquetées (un « leader »). Cela simplifie le défi d’ingénierie consistant à construire une blockchain hautes performances, mais introduit aussi un goulot économique potentiel : ces leaders peuvent extraire de la valeur. En général, pendant la fenêtre où un nœud est sélectionné comme leader, il a un pouvoir total sur les transactions qu’il inclut dans le bloc. Pour une blockchain qui traite des activités financières de toute taille, le leader est dans une position privilégiée. Si ce leader unique décide de ne pas inclure une transaction, la seule mesure de remédiation consiste à attendre le leader suivant qui sera disposé à inclure cette transaction.

Dans un réseau sans permission, les leaders ont une motivation à extraire de la valeur, ce que l’on appelle communément MEV. Le MEV dépasse largement le cadre de l’ « attaque de type sandwich » contre les transactions AMM. Même si le leader ne peut que retarder le paquetage de quelques dizaines de millisecondes, cela peut lui rapporter des profits considérables tout en réduisant l’efficacité de l’application sous-jacente. Un carnet d’ordres qui ne traite en priorité que les transactions de certains traders laisse tout le monde en concurrence dans un environnement injuste. Dans le pire des cas, le leader peut devenir extrêmement hostile au point que les traders quittent complètement la plateforme.

Supposons qu’il y ait une hausse des taux : le prix de l’ETH chute immédiatement de 5 %. Chaque teneur de marché sur le carnet d’ordres s’empresse d’annuler ses ordres en attente et de soumettre de nouveaux ordres aux nouveaux prix. Pendant ce temps, chaque arbitragiste soumet des transactions pour vendre l’ETH au prix d’ordres désormais obsolètes. Si ce carnet d’ordres fonctionne sur un protocole disposant d’un seul leader, ce leader aura un pouvoir immense. Le leader peut simplement choisir de réviser (c.-à-d. d’ignorer) toutes les annulations des teneurs de marché, permettant ainsi aux arbitragistes de réaliser d’énormes profits. Ou bien le leader peut ne pas examiner directement les opérations d’annulation, mais retarder ces annulations jusqu’après la confirmation de la transaction des arbitragistes. Le leader peut même insérer directement ses propres transactions d’arbitrage afin de tirer pleinement parti de l’écart de prix.

Deux revendications fondamentales

Face à ces avantages, la participation active des teneurs de marché devient économiquement inefficiente : tant que le prix fluctue, ils peuvent être désavantagés. Le problème se résume au fait que les leaders disposent de trop de privilèges dans deux aspects clés : 1) le leader peut censurer les transactions de n’importe qui d’autre, et 2) le leader peut voir les transactions des autres et soumettre ses propres transactions en réponse. N’importe lequel de ces deux problèmes peut se révéler catastrophique.

Un exemple

Nous pouvons cerner précisément où se situe le problème à l’aide de l’exemple suivant. Considérons une vente aux enchères avec deux enchérisseurs, Alice et Bob, où Bob est également le leader du bloc où l’enchère a lieu. (Le réglage avec seulement deux enchérisseurs sert à illustrer ; quel que soit le nombre d’enchérisseurs, le même raisonnement s’applique.)

L’enchère accepte les offres pendant la durée requise pour générer le bloc ; supposons de t=0 à t=1. Alice soumet son offre bA à tA, et Bob soumet bB à tB > tA. Comme Bob est le leader de ce bloc, il peut toujours garantir qu’il agira en dernier. Alice et Bob disposent aussi d’une source de vérité de prix d’actifs qui s’actualise en continu (par exemple le prix médian d’une bourse centralisée). À l’instant t, supposons que ce prix soit pt. Nous supposons que, pour tout instant t, la prévision du marché concernant le prix de l’actif à la fin de l’enchère (t=1) est toujours égale au prix réel actuel pt. Les règles de l’enchère sont simples : celui parmi Alice et Bob qui a l’offre la plus élevée gagne l’enchère et paie le montant de son offre.

Besoin de résistance à la censure

Voyons maintenant ce qui se passe quand Bob peut tirer parti du fait qu’il est le leader de cette enchère. Si Bob peut censurer l’offre d’Alice, il est évident que l’enchère s’effondre. Comme il n’y a pas d’autres enchérisseurs, Bob n’a qu’à faire une offre d’un montant arbitrairement faible pour être assuré de gagner. Cela conduit à un bénéfice essentiellement nul (0) à la clôture de l’enchère.

Besoin caché

La situation devient plus complexe si Bob ne peut pas censurer directement l’offre d’Alice, mais peut tout de même la voir avant de formuler sa propre offre. Dans ce cas, Bob dispose d’une stratégie simple. Lorsqu’il fait son offre, il lui suffit de vérifier si ptB > bA est vrai. Si c’est le cas, l’offre de Bob n’est que légèrement supérieure à bA ; sinon, Bob n’offre rien du tout.

En appliquant cette stratégie, Bob place Alice face à une sélection adverse défavorable. La seule façon qu’Alice gagne est si l’actualisation du prix fait que son offre dépasse finalement la valeur attendue de l’actif. Chaque fois qu’Alice gagne l’enchère, elle s’attend à perdre de l’argent ; il vaut mieux qu’elle ne participe tout simplement pas. À mesure que tous les concurrents disparaissent, Bob peut à nouveau faire une offre d’un montant arbitrairement faible et gagner, et l’enchère obtient en pratique un bénéfice de 0.

Le point clé ici est que la durée de cette enchère n’a aucune importance. Tant que Bob peut censurer l’offre d’Alice, ou voir l’offre d’Alice avant de faire la sienne, cette enchère est vouée à échouer.

Les mêmes principes s’appliquent à tout environnement d’actifs de trading à haute fréquence : trading spot, contrats perpétuels ou trading sur des plateformes de dérivés. Si un leader disposant du pouvoir de Bob dans cet exemple existe, ce leader peut provoquer l’effondrement total du marché. Pour que des produits on-chain servant ces cas d’usage soient réellement viables, ils ne doivent jamais conférer ces pouvoirs aux leaders.

Comment ces problèmes se manifestent-ils dans la pratique aujourd’hui ?

L’histoire ci-dessus dépeint un tableau sombre des transactions on-chain sur tout protocole de leader unique sans permission. Pourtant, pourquoi les volumes de transactions DEX sur des protocoles à leader unique continuent-ils d’être sains ? En pratique, deux forces combinées compensent ces problèmes :

• Les leaders ne profitent pas pleinement de leur pouvoir économique, car ils investissent généralement eux-mêmes massivement dans le succès de la blockchain sous-jacente ;
• Les applications ont déjà construit des contournements pour éviter d’être aussi fragiles face à ces problèmes.

Bien que ces deux facteurs aient jusqu’ici permis au financement décentralisé (DeFi) de fonctionner, à long terme, ils ne suffisent pas à rendre les marchés on-chain réellement compétitifs avec les marchés off-chain.

Pour obtenir le rôle de leader sur une blockchain où l’activité économique est significative, il faut une quantité importante de mise (staking). Ainsi, soit les leaders détiennent eux-mêmes une grande quantité de mise, soit ils ont une réputation suffisamment forte pour que d’autres détenteurs de tokens leur délèguent leur mise. Dans tous les cas, les grands opérateurs de nœuds sont généralement des entités connues dont la réputation est en jeu. Au-delà de la réputation, cette mise implique aussi qu’ils ont une motivation financière à faire fonctionner correctement leur blockchain. C’est précisément pour cette raison que, dans une large mesure, nous n’avons pas encore vu les leaders tirer pleinement parti de leur pouvoir de marché comme décrit ci-dessus — mais cela ne signifie pas que ces problèmes n’existent pas.

Premièrement, s’appuyer sur la bonne volonté des opérateurs de nœuds par la pression sociale et en invoquant leurs motivations à long terme n’est pas une base solide pour l’avenir de la finance. À mesure que l’activité financière on-chain augmente, les profits potentiels des leaders augmentent également. Plus cette potentialité grandit, plus il devient difficile au niveau social de faire en sorte que le comportement des leaders aille à l’encontre de leurs intérêts directs immédiats.

Deuxièmement, la capacité qu’a un leader d’exploiter son pouvoir de marché se situe sur un spectre allant d’une situation bénigne jusqu’à un effondrement complet du marché. Les opérateurs de nœuds peuvent pousser unilatéralement à l’exploitation de leur pouvoir pour obtenir des profits plus élevés. Lorsque certains opérateurs franchissent la limite admise, les autres suivent rapidement. Les actes d’un seul nœud peuvent sembler insignifiants, mais lorsque tout le monde change, l’impact devient évident.

Peut-être que l’exemple le plus parlant de ce phénomène est celui des jeux de timing (Timing Games) : les leaders tentent d’annoncer leur production de bloc aussi tard que possible tant que le protocole reste efficace, afin d’obtenir des récompenses plus élevées. Quand les leaders deviennent trop agressifs, cela entraîne l’allongement du temps de production des blocs et des sauts de blocs. Bien que la rentabilité de ces stratégies soit largement connue, si les leaders choisissent de ne pas jouer à ces jeux, c’est principalement parce qu’ils préfèrent agir en tant que « bons gérants » de la blockchain. Mais c’est un équilibre social fragile. Dès qu’un seul opérateur de nœuds commence à jouer à ces stratégies pour obtenir des récompenses plus élevées sans conséquences, les autres opérateurs se joindront rapidement.

Les jeux de timing ne sont qu’un exemple de la façon dont les leaders peuvent augmenter leurs profits sans exploiter pleinement leur pouvoir de marché. Les leaders peuvent aussi mettre en œuvre de nombreuses autres mesures qui se font au détriment des applications afin d’augmenter leurs récompenses. Pris isolément, ces mesures peuvent sembler acceptables pour les applications, mais au final, la balance penche vers un point où le coût d’exécuter on-chain dépasse les bénéfices.

Un autre facteur permettant au DeFi de fonctionner est que les applications déplacent la logique importante off-chain, ne publiant on-chain que le résultat. Par exemple, tout protocole nécessitant une vente aux enchères rapide l’exécute off-chain. Ces applications font généralement tourner leurs mécanismes requis sur un ensemble de nœuds autorisés afin d’éviter les problèmes posés par des leaders malveillants. Par exemple, UniswapX exécute sa vente aux enchères hollandaise en dehors du réseau principal Ethereum pour finaliser les transactions ; de façon similaire, CowSwap exécute ses ventes aux enchères en vrac off-chain.

Bien que cela fonctionne pour les applications, cela met la proposition de valeur de la couche de base et de la construction on-chain dans une situation précaire. Dans un monde où la logique d’exécution des applications se fait off-chain, la couche de base n’est plus essentiellement qu’une couche de règlement. L’un des arguments les plus forts du DeFi est la composabilité. Dans un monde où toute l’exécution se produit off-chain, ces applications vivent essentiellement dans un environnement isolé. Le recours à l’exécution off-chain ajoute aussi de nouvelles hypothèses au modèle de confiance des applications. Le fonctionnement des applications ne dépend plus seulement de l’activité de la chaîne sous-jacente ; il faut aussi que cette infrastructure off-chain fonctionne correctement.

Comment obtenir de la prévisibilité

Pour résoudre ces problèmes, nous avons besoin que les protocoles satisfassent deux propriétés : des règles cohérentes de regroupement et d’ordonnancement des transactions, ainsi que la confidentialité des transactions avant leur inclusion (pour des définitions strictes de ces propriétés et des discussions plus approfondies, voir cet article).

Demande de base 1 : résistance à la censure

Nous résumons la première propriété par la résistance à la censure à court terme. Si toute transaction qui arrive à un nœud honnête est garantie d’être incluse dans le prochain bloc potentiellement disponible, alors le protocole est résistant à la censure à court terme :

Résistance à la censure à court terme : Toute transaction valide qui arrive à un nœud honnête à temps doit être empaquetée dans le prochain bloc potentiellement disponible.

Plus précisément, nous supposons que le protocole fonctionne sur une horloge fixe, chaque bloc étant produit à un instant prédéfini, par exemple toutes les 100 millisecondes. Ce qu’il faut garantir alors, c’est qu’une transaction qui arrive au nœud honnête à t=250ms soit incluse dans le bloc produit à t=300ms. L’adversaire ne doit pas avoir le droit de choisir de manière arbitraire d’empaqueter certaines transactions qu’il entend et d’en omettre d’autres.

L’esprit de cette définition est que les utilisateurs et les applications devraient disposer d’une manière extrêmement fiable de faire atterrir leurs transactions à tout moment. Il ne devrait pas arriver qu’un nœud unique, par accident (malveillant ou simplement en panne de fonctionnement), fasse que les transactions ne puissent pas atterrir. Bien que cette définition exige une garantie d’inclusion pour les transactions arrivant à n’importe quel nœud honnête, en pratique, obtenir cela pourrait être trop coûteux. Une caractéristique importante est que le protocole devrait être robuste : le comportement au point d’entrée pour l’inclusion on-chain devrait être très prévisible et facile à raisonner.

Les protocoles à leader unique sans permission ne satisfont évidemment pas cette propriété : si, à tout moment, le leader unique est un nœud byzantin, il n’existe aucun autre moyen de faire atterrir les transactions. Cependant, même un ensemble de quatre nœuds capables de garantir l’inclusion des transactions dans chaque créneau améliore considérablement les options pour les utilisateurs et les applications. Échanger une partie de la performance contre un protocole qui permet de façon fiable aux applications de prospérer en vaut la peine. Il reste encore beaucoup de travail pour trouver le bon compromis entre robustesse et performance, mais les garanties fournies par les protocoles actuels ne sont pas suffisantes.

Étant donné que le protocole peut garantir l’inclusion, l’ordonnancement est naturellement une question de bon sens dans une certaine mesure. Le protocole peut utiliser librement n’importe quelle règle d’ordonnancement déterministe qu’il souhaite afin de garantir un ordonnancement cohérent. La solution la plus simple consiste à trier selon les frais de priorité, ou éventuellement à permettre aux applications de trier avec flexibilité les transactions qu’elles doivent ordonner pour interagir avec leur état. La meilleure façon d’ordonner les transactions reste un domaine de recherche actif, mais quoi qu’il en soit, les règles d’ordonnancement ne comptent que si les transactions à ordonner sont effectivement incluses.

Demande de base 2 : confidentialité

Après la résistance à la censure à court terme, la propriété la plus importante suivante est une forme de confidentialité que nous appelons « confidentialité ».

Confidentialité : Avant que le protocole ne finalise l’inclusion d’une transaction, aucune partie ne peut obtenir aucune information à propos de cette transaction, à l’exception du nœud qui a reçu la transaction.

Un protocole doté de la propriété de « confidentialité » peut autoriser les nœuds à voir, en clair, toutes les transactions soumises à eux, mais il exige que le reste du protocole reste à l’aveugle jusqu’à ce que le consensus soit atteint et que l’ordre des transactions soit déterminé dans le journal final. Par exemple, le protocole peut utiliser un chiffrement à base de verrous temporels de sorte à cacher l’intégralité du contenu des blocs avant une date limite ; ou bien le protocole peut utiliser un chiffrement à seuil de sorte que le bloc se déchiffre immédiatement après que le comité l’a approuvé pour une confirmation irréversible.

Cela signifie que les nœuds peuvent abuser des informations obtenues à partir de n’importe quelle transaction qui leur est soumise, mais le reste du protocole ne saura ce qu’ils ont atteint comme consensus qu’ensuite. Lors de la divulgation des informations de transaction au reste du réseau, la transaction a déjà été ordonnée et confirmée, de sorte qu’aucune autre partie ne peut la « devancer » (front-run). Pour que cette définition soit utile, cela implique effectivement que plusieurs nœuds puissent atterrir des transactions dans n’importe quel créneau donné.

Nous abandonnons l’utilisation d’une notion plus forte dans laquelle l’utilisateur n’apprend l’information qu’avant la confirmation de la transaction (par exemple dans un mempool chiffré) car le protocole a besoin d’effectuer certaines étapes en tant que filtre des transactions poubelles. Si le contenu d’une transaction est caché complètement à l’ensemble du réseau, le réseau ne pourra pas distinguer les transactions poubelles des transactions significatives. La seule façon de résoudre ce problème est de divulguer une partie de métadonnées non cachées comme faisant partie de la transaction, par exemple l’adresse du payeur des frais qui sera facturée, que la transaction soit valide ou non.

Cependant, ces métadonnées peuvent divulguer suffisamment d’informations pour permettre aux adversaires de les exploiter. C’est pourquoi nous préférons que le fait qu’une transaction soit entièrement visible à un nœud unique, tandis que les autres nœuds du réseau n’aient aucune visibilité. Mais cela signifie aussi que, pour que cette propriété soit utile, les utilisateurs doivent, dans chaque créneau, disposer d’au moins un nœud honnête servant de point d’entrée pour l’inclusion des transactions.

Un protocole à la fois résistant à la censure à court terme et offrant de la confidentialité constitue une base idéale pour construire des applications financières. Revenons à notre exemple d’enchères exécutées on-chain : ces deux propriétés résolvent directement la façon dont Bob pourrait provoquer l’effondrement du marché. Bob ne peut ni censurer les offres d’Alice, ni utiliser les offres d’Alice pour lui fournir des informations permettant d’alimenter sa propre offre ; cela résout exactement le problème de notre exemple précédent.

Avec la résistance à la censure à court terme, toute personne qui soumet une transaction (qu’il s’agisse d’une transaction ou d’une offre d’enchère) peut garantir qu’elle sera empaquetée immédiatement. Les teneurs de marché peuvent modifier leurs ordres ; les enchérisseurs peuvent augmenter rapidement leurs offres ; les liquidations peuvent être incluses efficacement. Les utilisateurs peuvent être sûrs que toute action qu’ils entreprennent sera exécutée immédiatement. Cela permet, en retour, que la prochaine génération d’applications financières du monde réel à faible latence soit entièrement construite on-chain.

Pour que la blockchain rivalise vraiment avec les infrastructures financières existantes, voire les dépasse, il ne s’agit pas seulement de résoudre le problème du débit.