a16z discute de l'avenir du marché en chaîne : pourquoi la prévisibilité est-elle une base essentielle ?

Rédigé par : Pranav Garimidi, Joachim Neu et Max Resnick, a16z crypto

Compilation : Glendon, Techub News

La blockchain peut désormais affirmer avec confiance 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 il reste encore une marge d’augmentation de plusieurs ordres de grandeur.

Cependant, au-delà du simple débit brut, les applications financières ont besoin de prévisibilité. Lorsqu’une transaction est envoyée — qu’il s’agisse d’une transaction, d’une enchère ou d’une option d’exercice — le bon fonctionnement du système financier dépend de garanties fiables quant à l’instant où la transaction sera incluse on-chain. Si une transaction subit un délai imprévisible (qu’il s’agisse d’une attaque malveillante ou d’un événement fortuit), de nombreuses applications deviennent inutilisables. Pour que les applications financières on-chain restent compétitives, la blockchain doit fournir des garanties d’inclusion à court terme : une fois qu’une transaction valide est soumise au réseau, elle est garantie d’être incluse le plus rapidement possible.

Par exemple, prenons le carnet d’ordres on-chain. Un carnet d’ordres efficace nécessite que les market makers fournissent la liquidité en maintenant en continu leurs ordres. Le problème central auquel sont confrontés les market makers consiste à réduire autant que possible le spread achat-vente tout en évitant la sélection adverse causée par un écart entre leurs cotations et le niveau global du marché. Pour cela, les market makers doivent mettre à jour en permanence leurs ordres afin de refléter les changements du monde extérieur. Par exemple, si une déclaration de la Réserve fédérale fait bondir les prix des actifs, les market makers doivent réagir immédiatement et mettre à jour leurs ordres à un nouveau prix. Dans ce cas, si les transactions de mise à jour des ordres ne sont pas mises on-chain à temps, les arbitragistes exécuteront les ordres à un prix devenu obsolète, entraînant une perte pour les market makers. Les market makers doivent alors élargir le spread afin de réduire l’exposition au risque de ce type d’événement, ce qui diminue la compétitivité des places de marché on-chain.

Un mécanisme d’inclusion des transactions prévisible offre aux market makers une solide assurance, leur permettant de répondre rapidement aux événements off-chain et de maintenir un fonctionnement efficace du marché on-chain.

Situation actuelle et besoins futurs

À l’heure actuelle, les blockchains existantes ne fournissent que des garanties d’inclusion effectives à l’échelle de quelques secondes. Bien que ces garanties soient suffisantes pour des applications comme le paiement, elles sont trop faibles pour un grand nombre d’applications financières nécessitant une réponse en temps réel. Prenons le carnet d’ordres : pour un market maker, si les transactions des arbitragistes pouvaient entrer dans un bloc plus tôt, alors la garantie « incluse dans les prochaines quelques secondes » serait dénuée de sens. En l’absence de garanties d’inclusion solides, les market makers ne peuvent que faire face à un risque de sélection adverse plus élevé en élargissant le spread, offrant ainsi aux utilisateurs de moins bonnes conditions de prix. Cela rend en retour les transactions on-chain moins attrayantes que celles effectuées sur d’autres places de marché capables d’offrir des garanties plus fortes.

Pour que la blockchain réalise véritablement sa vision de devenir une infrastructure de capital moderne pour le marché, les développeurs doivent résoudre ces problèmes afin de permettre l’essor d’applications à forte valeur telles que les carnets d’ordres.

À quel point est-il difficile d’obtenir de la prévisibilité ?

Renforcer les garanties d’inclusion des transactions sur les blockchains existantes afin de soutenir des applications de niveau financier est une tâche difficile. Certains protocoles s’appuient actuellement sur un seul nœud (c’est-à-dire un « leader ») pour déterminer l’ordre d’inclusion des transactions à tout moment. Même si cela simplifie la mise en œuvre technique d’une blockchain à haut débit, cela introduit aussi un goulot économique potentiel, permettant au leader de capter de la valeur. En général, pendant la fenêtre où un nœud est leader, il dispose d’un contrôle total sur les transactions incluses dans le bloc.

Pour toute blockchain traitant des activités financières, le leader se trouve dans une position privilégiée. Si ce leader unique décide de ne pas inclure une transaction, l’unique recours consiste à attendre le leader suivant qui acceptera d’inclure cette transaction. Sur les réseaux sans permission, les leaders ont une incitation à en tirer profit, ce qui est généralement appelé MEV (Maximum Extractable Value, valeur maximale extractible). L’impact du MEV va bien au-delà d’opérations du type « se glisser au milieu des transactions d’un AMM ». Même si le leader n’est capable que de retarder l’inclusion de quelques dizaines de millisecondes, il peut en tirer des profits considérables et réduire l’efficacité des applications sous-jacentes. Si le carnet d’ordres ne traite que par priorité les transactions de certains acteurs, tous les autres se retrouveront dans un environnement de concurrence injuste. Dans le pire des cas, les actions du leader peuvent même exaspérer les traders et les pousser à quitter totalement la plateforme.

Supposons que les taux d’intérêt augmentent : le prix de l’ETH chute immédiatement de 5 %. Tous les market makers du carnet d’ordres vont se précipiter pour annuler leurs ordres et soumettre de nouveaux ordres à de nouveaux prix. Dans le même temps, tous les arbitragistes soumettront des ordres pour vendre l’ETH au prix des anciens ordres. Si ce carnet d’ordres fonctionne sur un protocole contrôlé par un seul leader, alors ce leader aura un pouvoir énorme. Le leader peut simplement interdire les annulations de tous les market makers, permettant ainsi aux arbitragistes de réaliser d’importants profits. Ou bien le leader peut ne pas interdire directement les annulations, mais retarder leur exécution jusqu’à ce que les arbitragistes aient terminé leurs transactions. Le leader peut même insérer directement ses propres transactions d’arbitrage afin d’exploiter entièrement les écarts de prix pour gagner.

Un conflit de demandes idéales : la nécessité de l’anti-censure et du masquage de l’information

Face à ces avantages, participer activement devient non rentable pour les market makers ; à chaque fois que le prix bouge, ils risquent d’être exploités. Le point clé est que les leaders du marché disposent de deux privilèges excessifs : 1) le leader peut censurer les transactions des autres ; 2) le leader peut voir les transactions des autres et, sur cette base, soumettre ses propres transactions pour répondre. Chacun de ces deux problèmes peut entraîner des conséquences catastrophiques.

Exemple

Nous pouvons illustrer précisément ce problème avec l’exemple suivant. Supposons qu’il y ait une enchère avec deux enchérisseurs, Alice et Bob, et que Bob soit précisément le « leader » du bloc où se déroule l’enchère. (Ici, il n’y a que deux enchérisseurs uniquement pour des raisons de simplicité ; quelle que soit la quantité d’enchérisseurs, le même raisonnement s’applique.)

L’enchère accepte les enchères soumises entre le début et la fin de la production du bloc, supposons de t=0 à t=1. Alice soumet une enchère bA à l’instant tA, et Bob soumet une enchère bB à un instant tB > tA. Comme Bob est le leader de ce bloc, il peut toujours garantir sa dernière enchère. Alice et Bob disposent également d’une source d’information sur le prix d’un actif qu’ils mettent à jour 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, à l’instant t, les deux parties ont la même attente concernant le prix de l’actif à la fin de l’enchère (t=1) : il est toujours pt. Autrement dit, à tout moment, Alice et Bob s’attendent à ce que le prix de l’actif à la fin de l’enchère soit égal au prix qu’elles voient actuellement. Les règles de l’enchère sont simples : celui d’Alice ou de Bob qui a l’enchère la plus élevée remporte l’enchère et paie son enchère.

La nécessité de l’anti-censure

Regardons maintenant ce qui se passe si Bob peut tirer parti de son avantage de leader. S’il peut empêcher l’enchère d’Alice, évidemment l’enchère échoue. Bob n’a qu’à placer une enchère arbitrairement petite et s’assurer qu’il remporte l’enchère, puisque les autres enchères n’existent pas. Cela conduit l’enchère à être conclue avec presque zéro revenu.

Le besoin de masquage de l’information

Une situation plus complexe est celle où Bob ne peut pas empêcher directement l’enchère d’Alice, mais peut quand même voir l’enchère d’Alice avant de placer la sienne. Dans ce cas, Bob dispose d’une stratégie simple : lorsqu’il enchérit, il n’a qu’à vérifier si ptB est supérieur à bA. Si c’est le cas, Bob enchérit un montant légèrement supérieur à bA ; sinon, Bob ne soumet aucune enchère. En adoptant cette stratégie, Bob entraîne une sélection adverse contre Alice. Alice ne remportera que si le mouvement des prix fait en sorte que son enchère finisse par être supérieure à la valeur attendue de l’actif. Chaque fois qu’Alice gagne l’enchère, elle s’attend à perdre de l’argent, et il vaut mieux pour elle ne pas participer à l’enchère. À mesure que tous les autres enchérisseurs disparaissent, Bob n’a une fois encore qu’à placer un montant arbitrairement petit pour gagner, et l’enchère obtient en pratique un revenu nul.

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

Les principes de cet exemple s’appliquent à n’importe quel scénario de trading d’actifs à haute fréquence, que ce soit sur le marché spot, sur des contrats perpétuels ou sur des exchanges de dérivés : tant qu’il existe un leader disposant d’un pouvoir immense comme Bob dans cet exemple, il peut faire s’effondrer le marché tout entier. Pour que les produits on-chain qui servent ces cas d’usage puissent continuer à fonctionner, ils ne doivent jamais conférer aux leaders de tels pouvoirs.

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

La description ci-dessus brosse un tableau sombre de tout échange de transactions on-chain sur des protocoles de leader unique sans permission. Cependant, pourquoi les volumes de transaction sur des DEX (bourses décentralisées) de nombreux protocoles de leader unique restent-ils malgré tout sains ?

En réalité, la combinaison de deux forces permet de compenser les problèmes décrits ci-dessus :

Les leaders n’exploitent pas pleinement leur pouvoir économique, car ils ont en général aussi un intérêt considérable à la réussite de la chaîne d’approvisionnement sous-jacente ;

Les applications ont construit des mécanismes d’évitement adaptés pour se prémunir contre l’impact de ces problèmes.

Bien que ces deux facteurs permettent à la DeFi de continuer à prospérer, à long terme, ils ne suffisent pas pour faire réellement concurrencer les marchés on-chain avec les marchés off-chain.

Pour devenir un leader sur une blockchain où se déroule une activité économique importante, il faut détenir une quantité substantielle de collatéral (mise en garantie). Ainsi, soit les leaders détiennent eux-mêmes une grande quantité de collatéral, soit ils disposent d’une réputation suffisante pour obtenir des délégations de mise en garantie de la part d’autres détenteurs de jetons. Dans les deux cas, les grands opérateurs de nœuds sont généralement des entités bien connues et respectées. En plus de la réputation, ce collatéral signifie aussi que les opérateurs ont une motivation économique à faire en sorte que la chaîne associée se porte bien. C’est pourquoi nous ne voyons pratiquement pas les leaders exploiter pleinement leur pouvoir de marché comme décrit plus haut — mais cela ne signifie pas que ces problèmes n’existent pas.

D’abord, s’appuyer sur la bienveillance des opérateurs de nœuds, via la pression sociale et des incitations à long terme, n’est pas une base solide pour le futur financier. À mesure que l’activité financière on-chain augmente, les profits potentiels des leaders augmentent aussi. Plus ces profits potentiels sont élevés, plus il devient difficile, au niveau social, de contraindre un leader à se comporter autrement et à agir contre ses intérêts à court terme.

Ensuite, le degré avec lequel les leaders exploitent leur pouvoir de marché varie d’un spectre allant du comportement bénéfique jusqu’à provoquer l’effondrement complet du marché, et il y a tout un éventail de situations. Les opérateurs de nœuds peuvent pousser unilatéralement à une exploitation de leur pouvoir afin d’obtenir des profits plus élevés. Lorsque certains opérateurs testent les limites de ce qui est acceptable, d’autres opérateurs imitent rapidement. Le comportement d’un nœud pris isolément peut sembler insignifiant, mais lorsque tous les nœuds changent, l’impact devient évident.

La meilleure illustration de ce phénomène est peut-être le « jeu du timing » : lorsque le leader essaie de déclarer le bloc aussi tard que possible tout en garantissant que le bloc reste valide pour le protocole, il peut obtenir une récompense plus élevée. Cela entraîne une augmentation du temps de génération des blocs, voire, si le leader est trop agressif, certains blocs peuvent être sautés. Bien que l’on sache que ces stratégies sont rentables, les leaders s’abstiennent d’y participer afin de préserver un bon ordre de la chaîne.

Cependant, cet équilibre social est fragile. Dès qu’un opérateur de nœuds commence à utiliser ces stratégies pour obtenir une récompense plus élevée sans aucune pénalité, les autres opérateurs imiteraient rapidement. Le jeu du timing n’est qu’un exemple de la manière dont les leaders peuvent augmenter leur profit sans exploiter pleinement la puissance du marché. Les leaders peuvent aussi prendre de nombreuses autres mesures pour augmenter leurs revenus, mesures qui, bien souvent, vont à l’encontre des intérêts des applications. Considérées isolément, ces mesures peuvent fonctionner pour les applications, mais à mesure que l’échelle augmente, on atteint un point critique où les coûts on-chain dépassent les bénéfices.

Un autre facteur qui permet à la DeFi de continuer à fonctionner est que les applications déplacent une partie importante de leur logique off-chain, tout en publiant les résultats on-chain. Par exemple, tout protocole nécessitant d’exécuter rapidement une enchère le fait off-chain. En général, ces applications exécutent leurs mécanismes requis sur un ensemble de nœuds autorisés (permissionnés) afin d’éviter les conflits avec des leaders malveillants.

Par exemple, UniswapX exécute off-chain son enchère de type hollandaise pour traiter des transactions sur le mainnet Ethereum, et Cowswap exécute également off-chain ses enchères batch. Bien que cela soit viable pour les applications, cela met en péril l’architecture sous-jacente et la thèse de valeur des actifs construits on-chain. Si la logique d’exécution se trouve off-chain, l’infrastructure sous-jacente ne sert alors qu’au règlement (settlement). L’un des arguments les plus forts de la DeFi est la composabilité. Lorsque toute l’exécution se produit off-chain, ces applications vivent essentiellement dans un environnement insulaire. S’appuyer sur l’exécution off-chain ajoute aussi de nouvelles hypothèses au modèle de confiance de ces applications. En plus de dépendre du fait que la chaîne de base reste active, cette infrastructure off-chain doit aussi fonctionner correctement pour que l’application puisse fonctionner.

Comment réaliser la prévisibilité

Pour résoudre ces problèmes, les protocoles doivent satisfaire deux propriétés : des règles cohérentes d’inclusion et d’ordonnancement des transactions, ainsi qu’une confidentialité des transactions avant leur confirmation.

Condition primordiale : l’anti-censure

Nous résumons la première propriété par une forme d’anti-censure à court terme. Si un protocole peut garantir que toute transaction qui arrive à un nœud valide sera incluse dans le prochain bloc potentiellement généré, alors ce protocole possède une anti-censure à court terme.

Plus précisément, supposons que le protocole fonctionne sur un cycle d’horloge fixe, dans lequel chaque bloc est produit à un instant fixe ; par exemple, un bloc toutes les 100 millisecondes. Nous voulons alors garantir qu’une transaction qui arrive à un nœud valide à t=250 millisecondes sera incluse dans le bloc produit à t=300 millisecondes. L’adversaire ne devrait pas pouvoir choisir de n’inclure que certaines transactions qu’il a entendues, tout en en ignorant d’autres. L’idée centrale de cette définition est que les utilisateurs et les applications devraient disposer, à tout moment, d’un moyen extrêmement fiable de recevoir des transactions. Il ne devrait pas se produire un cas où, du fait du comportement malveillant d’un nœud ou d’une simple défaillance d’exploitation, une transaction soit perdue en sortie (drop) et ne puisse pas aboutir on-chain.

Bien que cette définition exige de garantir que toutes les transactions arrivant à des nœuds valides puissent être incluses, le coût pour y parvenir peut être trop élevé en pratique. Le point clé est que le protocole doit être suffisamment robuste pour que l’entrée des transactions on-chain puisse s’exécuter d’une manière extrêmement prévisible et facile à comprendre. Un protocole sans permission à leader unique ne satisfait évidemment pas cette propriété : si, à un moment donné, le leader unique se retrouve dans un état « byzantin », alors les transactions ne peuvent pas être acheminées on-chain autrement. Cependant, même un ensemble de quatre nœuds pouvant garantir l’inclusion des transactions dans chaque créneau (slot) augmente considérablement le nombre d’options dont disposent les utilisateurs et les applications pour faire aboutir des transactions. Pour garantir le fonctionnement stable des applications, il vaut la peine de sacrifier un peu de performance. Trouver le bon équilibre entre robustesse et performance reste un travail considérable à accomplir, mais les garanties offertes par les protocoles existants sont encore très loin d’être suffisantes.

Puisque le protocole garantit l’inclusion et l’intégrité des données, le mécanisme d’ordonnancement est, dans une certaine mesure, obtenu gratuitement. Le protocole peut librement utiliser n’importe quelle règle d’ordonnancement déterministe pour garantir la cohérence de l’ordonnancement. La solution la plus simple est d’ordonner par frais de priorité, ou de permettre aux applications d’ordonner de façon flexible les transactions avec lesquelles elles interagissent selon leur état. La meilleure façon d’ordonner les transactions reste un domaine de recherche actif, mais de toute façon, les règles d’ordonnancement ne sont utiles que s’il existe des transactions à ordonner.

Deuxième exigence : le masquage (confidentialité)

Après avoir acquis une anti-censure à court terme, la prochaine propriété la plus importante qu’un protocole doit fournir est une forme de confidentialité que nous appelons « masquage ».

Masquage : avant la confirmation finale de la transaction par le protocole, aucune partie autre que le nœud vers lequel la transaction est soumise ne peut connaître quoi que ce soit à propos de la transaction.

Un protocole avec masquage peut autoriser des nœuds à voir en clair toutes les transactions qui leur sont soumises, mais exige que le reste du protocole reste complètement aveugle au contenu des transactions jusqu’à ce que la finalisation de la consensus soit achevée et que l’ordre des transactions dans le journal final soit déterminé. Par exemple, le protocole pourrait utiliser un chiffrement à verrous temporels (time-lock encryption), de sorte que le contenu de l’ensemble du bloc reste caché jusqu’à une date limite ; ou bien le protocole pourrait utiliser le chiffrement à seuil (threshold encryption), de sorte que le bloc ne soit déchiffré qu’après que le comité a confirmé de manière irréversible.

Cela signifie qu’un nœud peut falsifier les informations de n’importe quelle transaction qui lui est soumise, mais que le reste du protocole ne connaît pas, avant d’aboutir au consensus, les détails précis du contenu des transactions sur lesquelles il s’appuie. Une fois que les informations sur la transaction sont révélées aux autres nœuds du réseau, la transaction a déjà été ordonnée et confirmée, de sorte qu’aucun autre nœud ne peut la devancer dans l’exécution. Pour que cette définition ait un sens pratique, cela implique que plusieurs nœuds puissent traiter les mêmes transactions sur une période de temps donnée.

Nous abandonnons des solutions plus fortes (par exemple, le fait que seuls les utilisateurs puissent connaître les informations de transaction avant la confirmation, comme avec un mempool chiffré), parce que le protocole a besoin de quelques étapes pour filtrer les transactions de rebut. Si le contenu des transactions était totalement caché à l’ensemble du réseau, il ne serait alors pas possible de distinguer les transactions de rebut des transactions valides. La seule solution consiste à divulguer dans les transactions certaines métadonnées non masquées, par exemple l’adresse du payeur qui est facturée que la transaction soit valide ou non. Cependant, ces métadonnées peuvent révéler suffisamment d’informations pour permettre aux adversaires de les exploiter. C’est pourquoi nous préférons qu’un seul nœud ait la connaissance complète des détails de la transaction, tandis que les autres nœuds du réseau ne puissent obtenir aucune information. Mais cela signifie que, pour que cette propriété soit utile, l’utilisateur doit disposer d’au moins un nœud honnête comme point d’entrée, afin de pouvoir soumettre avec succès des transactions pendant chaque créneau de temps.

Conclusion

Un protocole qui combine à la fois une résistance à la censure à court terme et une protection de la confidentialité fournit une base idéale pour construire des applications financières. Revenons à notre exemple précédent d’enchères tenues on-chain : ces deux propriétés résolvent directement le problème selon lequel Bob pourrait faire s’effondrer le marché. Bob ne peut ni censurer les enchères d’Alice ni utiliser les enchères d’Alice pour influencer ses propres enchères — ce qui règle exactement les problèmes 1 et 2 de notre exemple précédent.

Grâce à sa résistance à la censure du contenu à court terme, toute action de soumission de transaction (qu’il s’agisse d’une transaction ou d’une enchère) peut garantir une inclusion immédiate. Les market makers peuvent modifier leurs ordres ; les enchérisseurs peuvent enchérir rapidement ; les opérations de liquidation peuvent être exécutées efficacement. Les utilisateurs peuvent être sûrs que toute action qu’ils entreprennent sera exécutée immédiatement. À son tour, cela permettra à la prochaine génération d’applications financières réelles à faible latence de se construire entièrement au-dessus de la blockchain. Et pour que la blockchain puisse réellement rivaliser avec les infrastructures financières existantes, voire dépasser leurs performances, il ne faut pas seulement résoudre le problème du débit.