De Solana à l’EVM : une nouvelle voie pour les AMM propriétaires

Les Prop AMMs ont rapidement conquis 40 % du volume total des échanges sur Solana. Pourquoi sont-ils absents de l’écosystème EVM ?

Les Automated Market Makers propriétaires (Prop AMMs) se sont imposés comme acteurs majeurs de la DeFi sur Solana, générant désormais plus de 40 % du volume sur les principales paires. Ces plateformes spécialisées, gérées par des market makers professionnels, offrent une liquidité profonde et des prix compétitifs, principalement en limitant l’exposition des market makers au front-running d’arbitragistes exploitant des cotations obsolètes.

https://dune.com/the_defi_report/prop-amms

Pourtant, leur succès reste presque exclusivement cantonné à Solana. Pourquoi n’ont-ils pas percé dans l’écosystème EVM, y compris sur des Layer 2 rapides et peu onéreux comme Base ou Optimism ?

Cet article analyse la nature des Prop AMMs, les défis techniques et économiques qu’ils rencontrent sur les chaînes EVM, ainsi qu’une architecture innovante susceptible de les propulser au premier plan de la DeFi EVM.

Qu’est-ce qu’un Prop AMM ?

Un Prop AMM est un automated market maker dont la liquidité et la tarification d’un pool sont gérées activement par un market maker professionnel unique, contrairement à une fourniture passive par le public.

Contrairement aux AMMs classiques qui utilisent l’équation x * y = k pour fixer les prix, où x et y représentent les quantités des deux actifs du pool et k une constante, les Prop AMMs s’appuient sur une formule différente, généralement actualisée plusieurs fois par seconde. Ces Prop AMMs fonctionnent comme des boîtes noires : la formule exacte reste inconnue. Toutefois, le code du smart contract du Prop AMM d’Obric sur Sui est public (merci à @ markoggwp pour l’avoir signalé !), et son invariant k dépend des variables internes mult_x, mult_y et concentration. L’illustration ci-dessous montre la mise à jour continue de ces variables par le market maker.

Petite précision : le membre de gauche dans la formule de la courbe de prix d’Obric est plus complexe que x * y, mais l’essentiel à retenir pour comprendre les Prop AMMs est qu’il s’agit d’un invariant k, que le market maker ajuste pour modifier la courbe de prix.

Rappel : comment les prix sont-ils fixés sur un AMM ?

Le terme « courbe de prix » revient fréquemment, car il détermine le prix payé par l’utilisateur lors d’un trade sur un AMM et constitue l’élément que le market maker ajuste dans son Prop AMM pour actualiser les prix. Avant d’aller plus loin, il convient de comprendre comment les prix sont déterminés dans un AMM. Prenons une pool Uniswap v2 WETH-USDC sans frais. Le prix est fixé passivement par la formule x * y = k, où x et y sont les quantités des deux actifs du pool, et k une constante. Seuls les points de la courbe correspondent à des prix accessibles pour l’utilisateur.

Par exemple, considérons une pool WETH-USDC contenant 100 WETH et 400 000 USDC. Le point actuel sur la courbe est x = 100 WETH, y = 400 000 USDC, soit un prix initial de 400 000 USDC / 100 WETH = 4 000 USDC par WETH. En calculant le produit constant k, on obtient xy = k = 40 000 000. Si un trader souhaite acheter 1 WETH, il ajoute des USDC au pool, qui voit alors son solde WETH baisser à 99. Pour respecter l’invariant k, les nouveaux points x et y doivent rester sur la courbe, donc le solde USDC doit passer à 40 000 000 / 99 ≈ 404 040,40 USDC. Le trader paie donc 4 040,40 USDC pour ce WETH, un prix effectif supérieur au prix initial de 4 000 $ en raison de l’impact prix (slippage). C’est pourquoi la formule x y = k est aussi appelée courbe de prix, tout prix possible devant correspondre à un point de cette courbe.

Pourquoi un market maker opterait-il pour un AMM plutôt qu’un CLOB ?

Pourquoi un market maker choisirait-il un AMM pour assurer la liquidité ? Sur un Central Limit Order Book (CLOB) onchain, la mise à jour des cotations implique d’annuler et de remplacer potentiellement des milliers d’ordres limites individuels. Avec N ordres, il s’agit d’une opération linéaire O(N), lente et coûteuse en ressources sur la blockchain.

Si, à la place, toutes les cotations pouvaient être représentées par une seule courbe mathématique, il suffirait d’ajuster quelques paramètres pour modifier l’ensemble de la courbe. On passe alors d’un problème O(N) à une opération constante O(1).

Pour illustrer comment une courbe de prix (ex. x*y = k) génère des prix effectifs variés, prenons SolFi, le Prop AMM développé par Ellipsis Labs. Bien que la courbe de prix soit cachée, Ghostlabs a produit le graphique ci-dessous montrant le prix effectif SOL/USDC pour différentes quantités de SOL à échanger à un slot Solana donné (le numéro de slot, pour les lecteurs EVM, est analogue au numéro de bloc). Chaque ligne correspond à une pool WSOL/USDC distincte, illustrant la coexistence de plusieurs niveaux de prix. À mesure que le market maker ajuste la courbe de prix, le graphique évolue d’un slot à l’autre.

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

L’essentiel : avec une seule mise à jour portant sur quelques paramètres de la courbe de prix, le market maker peut ajuster à volonté le graphique des prix effectifs, sans avoir à modifier N ordres distincts. C’est la proposition de valeur centrale d’un Prop AMM : permettre une liquidité profonde, dynamique, avec une efficacité capitale et computationnelle maximale.

Pourquoi l’architecture de Solana est-elle idéale pour les Prop AMMs ?

Les Prop AMMs nécessitent une gestion active, donc deux conditions : des mises à jour peu coûteuses et une exécution prioritaire. Sur Solana, la faible coût des mises à jour permet d’obtenir cette priorité d’exécution.

Pourquoi ces deux points sont-ils cruciaux ? Les market makers ajustent leurs courbes de prix à la cadence de la chaîne, en fonction de leur inventaire et de l’évolution du prix indiciel de l’actif (par exemple, depuis des exchanges centralisés). Sur des chaînes rapides comme Solana, cela serait prohibitif si les mises à jour étaient onéreuses.

Ensuite, si le market maker ne parvient pas à placer sa mise à jour en haut du bloc, ses cotations obsolètes seront exploitées par des arbitragistes, entraînant des pertes garanties.

Sans ces deux propriétés, les market makers ne pourraient pas opérer efficacement, ce qui se traduirait par des prix moins avantageux pour les utilisateurs.

Par exemple, les Prop AMMs sur Solana comme HumidiFi mettent à jour leurs cotations jusqu’à 74 fois par seconde (merci à @ SliceAnalytics pour les données), comme illustré ci-dessous :

https://dune.com/queries/5980584/9644764

Du point de vue EVM, on pourrait demander : « Si un slot Solana dure environ 400 ms, comment un Prop AMM peut-il mettre à jour son prix plusieurs fois dans un même slot ? »

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

• EVM : Les transactions sont exécutées séquentiellement lors de la proposition et finalisation d’un bloc complet. Une mise à jour envoyée en milieu de bloc ne sera prise en compte qu’au bloc suivant.
• Solana : Le validateur leader ne construit pas un bloc complet avant diffusion. Il découpe les transactions en petits paquets (« shreds ») et les diffuse en continu au réseau. Plusieurs swaps peuvent avoir lieu dans un slot, mais une mise à jour de prix dans le shred #1 impacte le swap #1, tandis qu’une mise à jour dans le shred #2 impacte le swap #2.

À noter : les solutions comme Flashblocks sont comparables aux shreds de Solana. Selon @ Ashwinningg d’Anza Labs lors de la conférence CBER, un slot de 400 ms peut contenir jusqu’à 32 000 shreds, soit 80 shreds par milliseconde. Reste à savoir si des Flashblocks de 200 ms suffisent aux market makers face à l’architecture continue de Solana.

Pourquoi les mises à jour sont-elles si peu coûteuses sur Solana et comment cela garantit-il la priorité d’exécution ?

Bien que les Prop AMMs sur Solana soient des boîtes noires, il existe des librairies comme Pinocchio pour développer des programmes Solana optimisés en unités de calcul (CU). Le blog d’Helius détaille cette librairie (ici), montrant comment elle permet de réduire la consommation d’environ 4 000 CU à 100 CU.

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

Sur le plan de la priorité, Solana sélectionne les transactions ayant le ratio Frais / Compute Units le plus élevé (Compute Units étant l’équivalent du Gas sur EVM), similaire à l’EVM.

• Avec Jito, la formule est Jito Tip / Compute Units,
• sinon, Priority = (Frais de priorisation + Frais de base) / (1 + limite de CU + CU de signature + CU de verrouillage d’écriture) (https://solana.com/docs/core/fees)

En comparant la consommation d’unités de calcul d’une mise à jour Prop AMM et d’un swap Jupiter, on constate qu’une mise à jour Prop AMM est extrêmement économique, avec un ratio de 1 pour 1 000.

Mise à jour Prop AMM : Une simple mise à jour de courbe coûte à peine 109 CU chez Wintermute, avec des frais totaux de 0,000007506 SOL.

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Swap Jupiter : Un swap routé via Jupiter peut coûter jusqu’à 100 000 CU. Les frais totaux pour cette transaction étaient de 0,000005 SOL.

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

Grâce à cet écart considérable, un market maker peut obtenir une exécution prioritaire pour ses mises à jour en payant un faible supplément, atteignant un ratio Frais/CU bien supérieur à celui d’un swapper. Cela garantit une exécution rapide et prioritaire, protégeant le market maker du front-running par des flux toxiques.

Pourquoi les Prop AMMs ne sont-ils pas déjà présents sur EVM ?

Supposons que les mises à jour d’un Prop AMM impliquent l’écriture de variables qui définissent la courbe de prix d’une paire. Même si le code des Prop AMMs sur Solana reste confidentiel, l’implémentation d’Obric sur Sui montre que les variables de cotation sont écrites dans le smart contract via des fonctions d’update.

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

Merci à @ markoggwp pour cette découverte !

L’architecture EVM pose alors un obstacle majeur qui rend le modèle Prop AMM de Solana difficilement transposable.

Sur les blockchains Layer 2 OP-Stack comme Base et Unichain, les transactions sont ordonnées selon le Priority Fee par Gas (similaire à la priorisation par Frais / CU sur Solana).

Sur EVM, les écritures sont très coûteuses en gas. Une simple écriture via l’opcode SSTORE revient bien plus cher qu’une mise à jour sur Solana.

• SSTORE (de zéro à non-zéro) : ~22 100 gas
• SSTORE (de non-zéro à non-zéro) : ~5 000 gas
• Swap sur un AMM : ~200 000 à 300 000 gas

Le Gas sur EVM est l’équivalent des Compute Units sur Solana.

Ces chiffres supposent une seule écriture par transaction (cold writes), ce qui est réaliste car on n’envoie généralement qu’une mise à jour par transaction.

Bien qu’une mise à jour reste moins coûteuse qu’un swap, le ratio n’est que de 10x (une mise à jour pouvant utiliser plusieurs SSTORE), contre 1 000x sur Solana.

Deux conséquences majeures rendent le modèle Prop AMM de Solana plus risqué sur EVM :

1. La consommation de gas étant élevée, un faible priority fee ne permet pas d’obtenir un ratio Priority Fee / Gas élevé. Pour garantir une exécution prioritaire, il faut payer un priority fee plus important, donc plus coûteux.
2. Le ratio entre le gas d’une mise à jour et celui d’un swap sur EVM n’étant que de 1:10 contre 1:1 000 sur Solana, un arbitragiste n’a qu’à offrir un Priority Fee 10 fois supérieur à celui d’une mise à jour pour front-run le market maker, contre 1 000 fois sur Solana. Dans cet environnement, le front-running de mises à jour de prix est bien plus accessible sur EVM.

Des innovations comme EIP-1153 (TSTORE pour le stockage transitoire) permettent des écritures à 100 gas, mais ce stockage est éphémère et ne persiste que le temps d’une transaction. Il ne peut donc pas servir à conserver une mise à jour de prix pour un swap ultérieur (par exemple, pendant toute la durée d’un bloc).

Comment amener les Prop AMMs sur EVM ?

Avant d’y répondre, rappelons l’intérêt : les utilisateurs recherchent toujours de meilleures cotations, synonymes de conditions plus avantageuses. Les Prop AMMs sur Ethereum et les Layer 2 offriraient des prix plus compétitifs, aujourd’hui réservés à Solana et aux exchanges centralisés.

Pour rendre les Prop AMMs viables sur EVM, rappelons l’une des raisons de leur succès sur Solana :

• Les mises à jour Prop AMM en haut de bloc protègent le market maker du front-running, car elles consomment très peu de Compute Units et un faible fee suffit à obtenir un ratio Frais / CU élevé, surtout comparé aux swaps.

Comment amener ce modèle sur les blockchains EVM Layer 2 ? Deux options : réduire le coût des écritures, ou créer une voie prioritaire pour les mises à jour Prop AMM.

La première option (réduire le coût des écritures) est peu réaliste à cause du problème de croissance de l’état sur EVM, qui ouvrirait la voie au spam.

Nous proposons donc la création d’une voie prioritaire pour les mises à jour Prop AMM.

Une approche innovante, suggérée par @ MarkToda de l’équipe Uniswap, consiste à associer un smart contract Global Storage (repo ici) à une politique de builder spécialisée.

https://github.com/flashbots/global-storage-smart-contract

Fonctionnement :

• Global Storage Contract : un smart contract simple et unique sert de registre clé-valeur public. Les market makers y inscrivent les paramètres de leur courbe de prix (ex. : set(ETH-USDC_CONCENTRATION, 4000)).

Builder Policy : composant offchain clé. Les block builders reconnaissent les transactions envoyées à l’adresse du Global Storage contract et réservent automatiquement les 5 à 10 % initiaux du gas d’un bloc à ces transactions d’update, classées par priority fee. Ce mécanisme vise à éviter le spam.

Il est essentiel que la transaction ait pour destinataire l’adresse Global Storage, afin d’éviter que d’autres types de transactions ne bénéficient de cette priorité.

• Exemple d’algorithme de construction de bloc personnalisé avec rblib :

• Intégration Prop AMM : le smart contract Prop AMM du market maker lit les données de la courbe de prix depuis le Global Storage contract au moment du swap, pour déterminer la cotation à offrir à l’utilisateur.

Cette architecture résout efficacement les deux problèmes majeurs :

• Protection : la politique du builder crée une « voie rapide » garantissant que toutes les mises à jour de prix d’un bloc sont exécutées avant tout swap, éliminant le risque de front-running intra-bloc.
• Efficacité économique : les market makers ne rivalisent plus avec tous les utilisateurs DeFi pour atteindre le haut de bloc avec des gas élevés, mais uniquement avec les autres transactions d’update dans un marché local de frais. Cela réduit considérablement le coût de la priorité d’exécution.

Le swap d’un utilisateur s’effectue alors selon la courbe de prix définie par la mise à jour du market maker au tout début du bloc, garantissant une cotation fraîche et protégée. Ce modèle recrée l’environnement de mise à jour peu coûteux et prioritaire qui a permis aux Prop AMMs de prospérer sur Solana, ouvrant la voie à une nouvelle ère d’efficacité de marché sur EVM.

Cependant, ce modèle présente certaines limites qui restent à discuter en fin d’article.

Conclusion

La viabilité des AMMs propriétaires dépend de la résolution d’un enjeu économique central : garantir une exécution prioritaire et peu coûteuse pour éviter le front-running.

Si l’architecture EVM standard rend cela prohibitif et risqué, une nouvelle conception propose une alternative : en associant un smart contract Global Storage onchain à une politique de builder offchain, on crée une « voie rapide » dédiée aux mises à jour de prix. Ce modèle garantit l’exécution Top of Block pour les updates d’oracle tout en instaurant un marché local de frais, levant ainsi les principaux obstacles et rendant les Prop AMMs non seulement possibles, mais potentiellement transformateurs pour toute la DeFi EVM reposant sur des updates d’oracle prioritaires.

Questions ouvertes

• Les Prop AMMs opérant sur EVM à des vitesses de Flashblock de 200 ms sont-ils suffisamment rapides pour rivaliser avec l’architecture continue de Solana ?
• Sur Solana, la majorité du flux d’ordres AMM provient d’un agrégateur unique, Jupiter, qui propose un SDK pour connecter un AMM à l’agrégateur. Sur les blockchains EVM Layer 2, le flux est réparti entre plusieurs agrégateurs sans SDK public. Cela constitue-t-il un frein à l’essor des Prop AMMs sur EVM ?
• Comment les Prop AMMs sont-ils conçus pour que leurs mises à jour sur Solana n’utilisent qu’environ 100 CU ?
• Le modèle de voie rapide proposé ne prévoit que les mises à jour Prop AMM en haut de bloc. Si un Flashblock ne dure que 200 ms, il peut y avoir plusieurs swaps dans un Flashblock et un market maker peut vouloir mettre à jour le prix entre ces transactions. Comment cela peut-il être mis en œuvre ?
• Peut-on utiliser des langages comme Yul ou Huff pour écrire des programmes EVM optimisés, à l’image de Pinocchio sur Solana ?
• Comment les Prop AMMs se comparent-ils aux RFQ ?
• Comment empêcher les market makers de proposer une excellente cotation au bloc N affichée à l’utilisateur pour l’inciter à envoyer une transaction au bloc N+1, puis de mettre à jour la cotation au bloc N+1 avec une mauvaise cotation ? Comment Jupiter l’empêche-t-il ?
• Jupiter Ultra V3 introduit « Ultra Signaling » permettant aux Prop AMMs de distinguer entre flux toxique et non-toxique, pour offrir des cotations plus serrées de 3 bps. Quelle importance ont ces fonctionnalités d’agrégateur pour l’essor des Prop AMMs sur EVM ?

P.S. : Je recherche actuellement des créneaux pour intervenir en conférence sur ce sujet. Si vous êtes en lien avec des événements lors de Devconnect, je serais ravi d’échanger sur des opportunités de prise de parole !

Avertissement :

1. Cet article est une réimpression de [0xOptimus]. Tous droits réservés à l’auteur original [0xOptimus]. Pour toute objection à cette republication, veuillez contacter l’équipe Gate Learn qui traitera la demande rapidement.
2. Avertissement : Les opinions exprimées dans cet article n’engagent que l’auteur et ne constituent en aucun cas un conseil en investissement.
3. Les traductions de l’article dans d’autres langues sont réalisées par l’équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits sont interdits.