Pourquoi y a-t-il tant de Prop AMM sur Solana alors qu'il n'y en a toujours pas sur l'EVM ?

Titre original : dApps incontournables après le lancement du Mainnet Monad

Auteur original : Optimus

Source originale :

Reproduction : Mars Finance

Les AMM Prop ont rapidement conquis 40 % de tout le volume des transactions sur Solana. Pourquoi ne sont-elles pas encore apparues sur l'EVM ?

Les AMM propriétaires (Proprietary AMMs, abrégé en Prop AMMs) deviennent rapidement une force dominante dans l'écosystème DeFi de Solana, ayant déjà contribué à plus de 40 % du volume des transactions sur les principales paires de trading. Ces lieux de liquidité spécialisés, gérés par des teneurs de marché professionnels, peuvent offrir une liquidité profonde et des prix plus compétitifs, principalement en raison de leur capacité à réduire de manière significative le risque d'arbitrage par front-running utilisant des « prix obsolètes » (stale quotes).

Cependant, leur succès est presque entièrement limité à Solana. Même sur des réseaux Layer 2 rapides et peu coûteux comme Base ou Optimism, on ne trouve toujours que peu de traces des Prop AMM dans l'écosystème EVM. Pourquoi n'ont-elles pas pris racine sur l'EVM ?

Cet article aborde principalement trois questions : Qu'est-ce qu'un Prop AMM, quels obstacles techniques et économiques rencontrent-ils sur les chaînes EVM, et quelles nouvelles architectures prometteuses pourraient finalement les amener à l'avant-garde de la DeFi EVM.

Qu'est-ce que Prop AMM ?

Le Prop AMM est un type de teneur de marché automatique géré activement par un seul teneur de marché professionnel pour la liquidité et la tarification, au lieu d'être financé de manière passive par le grand public comme dans un AMM traditionnel.

Les AMM traditionnels (comme Uniswap v2) utilisent généralement la formule x * y = k pour déterminer le prix, où x et y représentent respectivement la quantité de deux actifs dans le pool, et k est une valeur constante. Dans un Prop AMM, la formule de tarification n'est pas fixe, mais est mise à jour fréquemment (généralement plusieurs fois par seconde). Étant donné que la plupart des mécanismes internes des Prop AMM sont considérés comme une « boîte noire », l'extérieur ne sait pas quel algorithme exact ils utilisent. Cependant, le code du contrat intelligent du Prop AMM Obric sur la chaîne Sui est public (merci à la découverte de @markoggwp), et sa constante k dépend des variables internes mult_x, mult_y et concentration. Le graphique ci-dessous montre comment le market maker met à jour ces variables en continu.

Un point à clarifier est que la formule à gauche de la courbe de tarification d'Obric est plus complexe qu'un simple x*y, mais la clé pour comprendre le Prop AMM est qu'il est toujours égal à une invariant k variable, et le market maker mettra continuellement à jour ce k pour ajuster la courbe de prix.

Révision : comment l'AMM détermine-t-il les prix ?

Dans cet article, nous mentionnerons plusieurs fois le concept de “courbe de prix”. La courbe de prix détermine le prix que les utilisateurs doivent payer lors de l'utilisation d'un AMM pour effectuer des transactions, et c'est également une partie qui est constamment mise à jour par les teneurs de marché dans un Prop AMM. Pour mieux comprendre cela, nous pouvons d'abord revoir le mode de tarification des AMM traditionnels.

Prenons l'exemple du pool WETH-USDC sur Uniswap v2 (supposons qu'il n'y ait pas de frais). Le prix est déterminé passivement par la formule x * y = k. Supposons qu'il y ait 100 WETH et 400 000 USDC dans le pool, le point de la courbe est alors x = 100, y = 400 000, ce qui correspond à un prix initial de 400 000 / 100 = 4 000 USDC/WETH. Par conséquent, la constante k = 100 * 400 000 = 40 000 000.

Si un trader souhaite acheter 1 WETH, il doit ajouter des USDC au pool, réduisant ainsi le WETH dans le pool à 99. Pour maintenir le produit constant k, le nouveau point (x, y) doit toujours se trouver sur la courbe, donc y doit devenir 40,000,000 / 99 ≈ 404,040.40. En d'autres termes, le trader paie environ 4,040.40 USDC pour 1 WETH, ce qui est légèrement supérieur au prix initial. Ce phénomène est appelé « slippage ». C'est pourquoi x*y=k est connu sous le nom de « courbe de prix » : tout prix échangeable doit se situer sur cette courbe.

Pourquoi les market makers choisissent-ils la conception AMM plutôt que le livre de commandes centralisé (CLOB) ?

Permettez-nous d'expliquer pourquoi les teneurs de marché souhaitent utiliser le design AMM pour faire du market making. Imaginez que vous êtes un teneur de marché qui cote sur un carnet d'ordres à limite centralisé (CLOB) sur la chaîne. Si vous souhaitez mettre à jour votre cotation, vous devez annuler et remplacer des milliers d'ordres à limite. Si vous avez N ordres, alors le coût de mise à jour est de l'ordre de O(N), ce qui est à la fois lent et coûteux sur la chaîne.

Et si vous pouviez représenter toutes les offres par une courbe mathématique ? Il vous suffirait de mettre à jour quelques paramètres définissant cette courbe, transformant ainsi l'opération O(N) en une complexité constante O(1).

Pour illustrer comment la « courbe de prix » correspond à différents intervalles de prix effectifs, nous pouvons nous référer à SolFi créé par Ellipsis Labs - un AMM Prop basé sur Solana. Bien que sa courbe de prix spécifique soit inconnue et cachée, Ghostlabs a tracé un graphique montrant les prix effectifs lors de l'échange de différentes quantités de SOL contre des USDC dans un certain slot de Solana (période de temps de bloc). Chaque ligne représente un pool WSOL/USDC différent, indiquant que plusieurs niveaux de prix peuvent exister simultanément. À mesure que les market makers mettent à jour la courbe de prix, ce graphique de prix effectif changera également entre différents slots.

Le point clé ici est qu'en mettant à jour seulement quelques paramètres de la courbe des prix, les teneurs de marché peuvent changer à tout moment la distribution des prix effectifs, sans avoir à modifier un par un N ordres. C'est exactement la proposition de valeur centrale de Prop AMM - elle permet aux teneurs de marché de fournir une liquidité dynamique et profonde avec une efficacité en capital et en calcul plus élevée.

Pourquoi l'architecture de Solana est-elle particulièrement adaptée aux Prop AMM ?

Le Prop AMM est un système « activement géré », ce qui signifie qu'il nécessite deux conditions clés :

1. Coûts de mise à jour faibles (cheap updates)

2. Droit d'exécution prioritaire (priority execution)

Sur Solana, les deux sont complémentaires : des mises à jour à faible coût signifient souvent que les mises à jour peuvent bénéficier d'une priorité d'exécution.

Pourquoi les teneurs de marché ont-ils besoin de ces deux points ? Tout d'abord, ils mettront à jour en continu les courbes de prix en fonction des variations de l'inventaire ou des fluctuations des prix des indices d'actifs (comme les prix des échanges centralisés) à la vitesse d'exécution de la blockchain. Sur des chaînes à haute fréquence comme Solana, si le coût de mise à jour est trop élevé, il sera difficile d'effectuer des ajustements à haute fréquence.

Deuxièmement, si les teneurs de marché ne parviennent pas à faire en sorte que les mises à jour se trouvent en haut du bloc, leurs anciennes offres seront « volées » par des arbitragistes, entraînant inévitablement des pertes. En l'absence de ces deux caractéristiques, les teneurs de marché ne pourront pas opérer efficacement, et les utilisateurs obtiendront également de moins bons prix de transaction.

Prenons l'exemple de HumidiFi, un Prop AMM sur Solana. Selon les données de @SliceAnalytics, ce market maker met à jour ses prix jusqu'à 74 fois par seconde.

Les joueurs venant de l'EVM pourraient se demander : « Le slot de Solana dure environ 400 ms, comment Prop AMM peut-il mettre à jour le prix plusieurs fois dans un seul slot ? »

La réponse réside dans l'architecture continue de Solana, qui est fondamentalement différente du modèle de blocs discrets de l'EVM.

· EVM : Les transactions sont généralement exécutées dans l'ordre après qu'un bloc complet a été proposé et confirmé. Cela signifie que les mises à jour envoyées en cours de route ne prendront effet qu'au bloc suivant.

· Solana : Les nœuds de validation Leader ne vont pas attendre le bloc complet, mais vont diviser les transactions en petits paquets de données (appelés « shred ») et les diffuser en continu sur le réseau. Un slot peut contenir plusieurs échanges, mais shred #1 的价格更新影响 swap #1, shred #2 的价格更新影响 swap #2.

Note : Les Flashblocks sont similaires aux shreds de Solana. Selon le partage de @Ashwinningg d'Anza Labs lors de la conférence CBER, chaque slot de 400 ms a une limite de 32 000 shreds, ce qui équivaut à 80 shreds par milliseconde. En ce qui concerne la question de savoir si des Flashblocks de 200 ms sont suffisamment rapides pour répondre aux besoins des market makers, cela reste une question ouverte par rapport à l'architecture continue de Solana.

Alors, pourquoi les mises à jour sur Solana sont-elles si bon marché ? Et comment cela conduit-il à une exécution prioritaire ?

Tout d'abord, bien que l'implémentation de Prop AMM sur Solana soit une boîte noire, il existe des bibliothèques comme Pinocchio qui permettent d'optimiser la manière d'écrire des programmes Solana. Le blog de Helius en parle très bien, et grâce à cette bibliothèque, la consommation de CU des programmes Solana peut passer d'environ 4000 CU à environ 100 CU.

Regardons maintenant la deuxième partie. À un niveau supérieur, Solana priorise les transactions en choisissant celles avec le ratio de frais / unités de calcul le plus élevé (les unités de calcul sont similaires au gaz de l'EVM), de manière similaire à l'EVM.

· Plus précisément, si vous utilisez Jito, la formule est Jito Tip / Compute Units

· Ne pas utiliser : Priority = ( frais prioritaires + frais de base ) / (1 + plafond CU + signature CU + verrou d'écriture CU )

En comparant les unités de calcul de la mise à jour de Prop AMM avec celles de Jupiter Swap, on constate que la mise à jour est extrêmement bon marché, avec un ratio de 1:1000.

Mise à jour de Prop AMM : mise à jour de la courbe simple très bon marché. La mise à jour de Wintermute est à partir de 109 CU, pour un coût total de seulement 0.000007506 SOL

Jupiter Swap : le swap via le routage Jupiter peut atteindre ~100,000 CU, frais totaux 0.000005 SOL

En raison de cette énorme différence, les teneurs de marché n'ont qu'à payer des frais très faibles pour mettre à jour les transactions, ce qui leur permet d'atteindre un ratio Fee/CU bien supérieur à celui de l'échange, garantissant ainsi que les mises à jour soient exécutées au sommet du bloc, les protégeant des attaques d'arbitrage.

Pourquoi Prop AMM n'a-t-il pas encore été déployé sur EVM ?

Supposons que la mise à jour de Prop AMM implique l'écriture de variables déterminant la courbe de prix des paires de transactions. Bien que le code de Prop AMM sur Solana soit une “boîte noire”, les market makers souhaitant garder leur stratégie secrète, nous pouvons utiliser cette hypothèse pour comprendre comment Obric met en œuvre Prop AMM sur Sui : les variables déterminant les devis de paires de transactions sont écrites dans le contrat intelligent via la fonction update.

Merci @markoggwp d'avoir découvert !

En utilisant cette hypothèse, nous avons découvert que l'architecture de l'EVM présente des obstacles majeurs, rendant le modèle Prop AMM de Solana non viable sur l'EVM.

En examinant cela, sur la blockchain OP-Stack Layer 2 (comme Base et Unichain), les transactions sont ordonnées par frais prioritaires par Gas (similaire à Solana qui classe par frais / CU).

Sur EVM, la consommation de Gas pour les opérations d'écriture est très élevée. Comparé aux mises à jour de Solana, le coût d'écriture d'une valeur sur EVM via l'opcode SSTORE est incroyable :

· SSTORE (0 → non 0) : ~22 100 gas

· SSTORE (non 0 → non 0) : ~5 000 gas

· Échange AMM typique : ~200,000–300,000 gaz

Note : Le Gas sur EVM est similaire à l'unité de calcul (CU) sur Solana. Le chiffre de gas SSTORE ci-dessus suppose qu'il n'y a qu'une seule écriture par transaction (écriture à froid), ce qui est raisonnable car il n'est généralement pas courant d'envoyer plusieurs mises à jour dans une seule transaction.

Bien que la mise à jour soit encore moins chère que l'échange, le taux d'utilisation du gaz n'est d'environ que 10 fois (les mises à jour peuvent impliquer plusieurs SSTORE), tandis que sur Solana, ce rapport est d'environ 1000 fois.

Cela a conduit à deux conclusions, rendant le même modèle Solana Prop AMM plus risqué sur EVM :

1. Une consommation de gaz élevée rend difficile la garantie des frais prioritaires pour les mises à jour, des frais prioritaires plus bas ne peuvent pas réaliser un ratio élevé de frais/gaz. Pour s'assurer que les mises à jour ne soient pas exécutées en premier et qu'elles se trouvent en haut du bloc, des frais prioritaires plus élevés sont nécessaires, ce qui augmente les coûts.

2. Le risque d'arbitrage sur l'EVM est plus élevé, le ratio de mise à jour du Gas et d'échange du Gas sur l'EVM est seulement de 1:10, tandis que sur Solana, il est de 1:1000. Cela signifie que les arbitragistes n'ont besoin d'augmenter les frais prioritaires que de 10 fois pour devancer les mises à jour des market makers, tandis que sur Solana, il faut les augmenter de 1000 fois. Avec ce ratio plus bas, les arbitragistes sont plus susceptibles de devancer les mises à jour des prix pour obtenir des prix dépassés, car le coût est faible.

Certaines innovations (comme TSTORE d'EIP-1153, pour le stockage temporaire) offrent environ 100 gas pour l'écriture, mais ce stockage est éphémère, valable uniquement dans une seule transaction, ne pouvant pas être utilisé pour rendre persistantes les mises à jour de prix pour une utilisation dans des échanges ultérieurs (par exemple, pendant toute la durée d'un bloc).

Comment introduire Prop AMM dans EVM ?

Avant de répondre, commençons par répondre à “pourquoi le faire” : les utilisateurs souhaitent toujours obtenir de meilleures offres de trading, ce qui signifie que les transactions sont plus avantageuses. Les Prop AMM d'Ethereum et de Layer 2 peuvent offrir aux utilisateurs des offres compétitives qui n'étaient auparavant disponibles que sur Solana ou les échanges centralisés.

Pour rendre le Prop AMM viable sur EVM, nous revenons sur l'une des raisons de son succès sur Solana :

· Protection des mises à jour au sommet du bloc : Sur Solana, les mises à jour de Prop AMM se trouvent au sommet du bloc, ce qui protège les teneurs de marché contre les transactions anticipées. Les mises à jour se trouvent en haut car la consommation d'unités de calcul est extrêmement faible, permettant un rapport coût/UC élevé même avec des frais bas, en particulier par rapport aux transactions de swap.

Alors, comment introduire la mise à jour de Prop AMM en haut de la blockchain EVM Layer 2 ? Il y a deux façons : soit réduire le coût d'écriture, soit créer un canal prioritaire pour la mise à jour de Prop AMM.

En raison du problème de croissance de l'état de l'EVM, la méthode de réduction des coûts d'écriture n'est pas très viable, car un SSTORE bon marché entraînera des attaques par état de déchet.

Nous proposons de créer un canal prioritaire pour la mise à jour de Prop AMM. C'est une solution viable et c'est le point central de cet article.

L'équipe Uniswap, @MarkToda, a proposé une nouvelle méthode pour réaliser : un contrat intelligent de stockage mondial + une stratégie de constructeur de blocs spécialisée.

Son fonctionnement est le suivant :

· Contrat de stockage global : déployer des contrats intelligents simples en tant que stockage de valeurs clés publiques. Les teneurs de marché écrivent les paramètres de la courbe de prix dans ce contrat (par exemple set(ETH-USDC_CONCENTRATION, 4000)).

· Stratégie de constructeur : Il s'agit d'un composant clé hors chaîne. Le constructeur de blocs identifie les transactions envoyées au contrat de stockage global, alloue 5 à 10 % du Gas du bloc à ces transactions de mise à jour et les classe par ordre de priorité en fonction des frais, afin d'empêcher les transactions indésirables.

Veuillez noter : les transactions doivent être envoyées directement à l'adresse de stockage global, sinon il n'est pas garanti qu'elles se trouvent en haut de la blockchain.

Exemple d'algorithme de construction de blocs personnalisé peut être consulté dans rblib.

Intégration de Prop AMM : Le contrat Prop AMM des teneurs de marché lit les données de courbe de prix à partir du contrat de stockage global lors de l'échange, afin de fournir des cotations.

Cette architecture résout habilement deux problèmes :

1. Protection : La stratégie de constructeur crée un “canal rapide”, garantissant que toutes les mises à jour de prix dans le bloc sont exécutées avant la transaction, éliminant ainsi le risque de front-running.

2. Coût-efficacité : les teneurs de marché ne sont plus en concurrence avec tous les utilisateurs de DeFi pour réaliser des transactions au sommet des blocs avec des frais de gas élevés, mais doivent simplement rivaliser sur le marché local des frais pour mettre à jour les transactions réservées au sommet des blocs, réduisant considérablement les coûts.

Les transactions des utilisateurs seront exécutées en fonction de la courbe de prix définie par le teneur de marché lors de la mise à jour initiale dans le même bloc, garantissant la fraîcheur et la sécurité des devis. Ce modèle reproduit dans l'EVM un environnement de mises à jour à faible coût et à haute priorité similaire à celui de Solana, ouvrant la voie au Prop AMM sur l'EVM.

Cependant, ce modèle présente également certains inconvénients, que je laisserai à la fin de cet article pour discussion.

Conclusion

La faisabilité du Prop AMM dépend de la résolution des problèmes économiques fondamentaux : une exécution bon marché et prioritaire pour prévenir le front-running.

Bien que l'architecture EVM standard rende de telles opérations coûteuses et risquées, une nouvelle conception offre une approche différente pour résoudre ce problème. En combinant des contrats intelligents de stockage global en chaîne et des stratégies de constructeurs hors chaîne, cette nouvelle conception permet de créer des « canaux rapides » dédiés, garantissant l'exécution des mises à jour au sommet du bloc tout en établissant un marché des frais local et contrôlé. Cela rend non seulement le Prop AMM réalisable sur EVM, mais pourrait également transformer l'ensemble de la DeFi EVM dépendant des mises à jour des oracles au sommet du bloc.

Questions ouvertes

· La vitesse de 200 ms de Flashblock de Prop AMM sur EVM est-elle suffisante pour rivaliser avec l'architecture continue de Solana ?

· La majeure partie du trafic AMM sur Solana provient d'un seul agrégateur, Jupiter, qui propose un SDK facilitant l'intégration des AMM. Cependant, sur Layer 2 EVM, le trafic est dispersé entre plusieurs agrégateurs sans SDK public, cela représente-t-il un défi pour Prop AMM ?

· Prop AMM sur Solana ne consomme qu'environ 100 CU, comment son mécanisme de mise en œuvre fonctionne-t-il ?

· Le modèle de voie rapide ne garantit que la mise à jour du sommet du bloc. Si plusieurs échanges sont présents dans un Flashblock, comment les teneurs de marché peuvent-ils mettre à jour les prix entre ces échanges ?

· Est-il possible d'écrire des programmes EVM optimisés dans des langages comme Yul ou Huff, similaires à la solution d'optimisation Pinocchio sur Solana ?

· Quelle est la comparaison entre Prop AMM et RFQ ?

· Comment empêcher les teneurs de marché de donner des cotations de qualité dans le bloc N pour inciter les utilisateurs, puis de les mettre à jour avec de mauvaises cotations dans le bloc N+1 ? Comment Jupiter se protège-t-il ?

· La fonction Ultra Signaling de Jupiter Ultra V3 permet au Prop AMM de distinguer le trafic nuisible du trafic inoffensif et d'offrir des cotations plus serrées. Quelle est l'importance de ces caractéristiques d'agrégateur pour le Prop AMM sur EVM ?