Pourquoi y a-t-il tant de Prop AMM sur Solana, alors que c'est toujours vide sur EVM ?

Titre original : Must-Watch dApps After Monad Mainnet Launch

Auteur original : Optimus, fondateur de Waterloo Blockchain

Traduction originale : Dingdang, Odaily

Les Prop AMMs ont rapidement capturé 40% du volume total des transactions sur Solana. Pourquoi n’apparaissent-ils pas encore sur EVM ?

Les Automated Market Makers propriétaires (Proprietary AMMs, ou Prop AMMs) deviennent rapidement la force dominante de l’écosystème DeFi sur Solana, représentant désormais plus de 40% du volume sur les principales paires de trading. Ces pools de liquidité spécialisés, opérés par des market makers professionnels, offrent une liquidité profonde et des prix plus compétitifs, principalement parce qu’ils réduisent considérablement le risque pour les market makers d’être victimes d’arbitrage sur des « cotations obsolètes » (stale quotes) par front-running.

Source de l’image : dune.com

Cependant, leur succès reste presque exclusivement limité à Solana. Même sur des réseaux Layer 2 rapides et peu coûteux comme Base ou Optimism, les Prop AMMs sont rares dans l’écosystème EVM. Pourquoi n’ont-ils pas pris racine sur EVM ?

Cet article explore 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 qu’un Prop AMM ?

Un Prop AMM est un automated market maker dont la liquidité et la tarification sont activement gérées par un seul market maker professionnel, contrairement aux AMM traditionnels où la liquidité est fournie de manière passive par le grand public.

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é des deux actifs dans le pool, et k est une constante. Dans un Prop AMM, la formule de tarification n’est pas fixe, mais est fréquemment mise à jour (souvent plusieurs fois par seconde). La plupart des mécanismes internes des Prop AMMs sont des « boîtes noires », et l’algorithme exact utilisé n’est pas connu du public. Cependant, le code du smart contract du Prop AMM Obric sur la blockchain Sui est public (merci à @markoggwp pour la découverte), et son invariant k dépend des variables internes mult_x, mult_y et concentration. Le schéma ci-dessous montre comment le market maker met continuellement à jour ces variables.

Il est important de préciser que : la formule à gauche de la courbe de tarification d’Obric est plus complexe que le simple x*y, mais la clé pour comprendre le Prop AMM est qu’elle est toujours égale à un invariant k variable, que le market maker met à jour en permanence pour ajuster la courbe de prix.

Rappel : comment un AMM détermine-t-il le prix ?

Dans cet article, nous évoquerons à plusieurs reprises le concept de « courbe de prix ». La courbe de prix détermine le prix que l’utilisateur doit payer lors d’une transaction sur un AMM, et c’est la partie que le market maker met constamment à jour dans un Prop AMM. Pour mieux comprendre cela, rappelons d’abord la méthode de tarification d’un AMM traditionnel.

Par exemple, prenons le pool WETH-USDC sur Uniswap v2 (en supposant 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 sur la courbe est alors x = 100, y = 400 000, ce qui donne un prix initial de 400 000 / 100 = 4 000 USDC/WETH. On obtient donc la constante k = 100 * 400 000 = 40 000 000.

Si un trader souhaite acheter 1 WETH, il doit ajouter des USDC au pool, ce qui réduit le WETH à 99. Pour maintenir le produit constant k, le nouveau point (x, y) doit rester sur la courbe, donc y doit devenir 40 000 000 / 99 ≈ 404 040,40. Cela signifie que le trader paie environ 4 040,40 USDC pour 1 WETH, soit un prix légèrement supérieur au prix initial. Ce phénomène est appelé « slippage » (glissement de prix). C’est pourquoi x*y=k est appelé « courbe de prix » : tout prix négociable doit se situer sur cette courbe.

Pourquoi les market makers choisissent-ils la conception AMM plutôt qu’un carnet d’ordres centralisé (CLOB) ?

Voyons pourquoi un market maker souhaite utiliser la conception AMM. Imaginez que vous êtes un market maker qui cote sur un carnet d’ordres à limite centralisé (CLOB) on-chain. Pour mettre à jour vos cotations, vous devez annuler et remplacer des milliers d’ordres à limite. Si vous avez N ordres, la mise à jour coûte O(N), ce qui est lent et coûteux sur la blockchain.

Mais si vous pouviez représenter toutes vos cotations par une courbe mathématique ? Vous n’auriez qu’à mettre à jour quelques paramètres de cette courbe, transformant ainsi une opération O(N) en une complexité constante O(1).

Pour illustrer visuellement comment la « courbe de prix » correspond à différentes plages de prix effectifs, nous pouvons nous référer à SolFi, créé par Ellipsis Labs sur Solana, un Prop AMM. Bien que sa courbe de prix exacte soit inconnue et cachée, Ghostlabs a dessiné un graphique montrant, pour un slot Solana donné (période de bloc), le prix effectif pour différents montants de SOL échangés contre USDC. Chaque ligne représente un pool WSOL/USDC différent, illustrant la coexistence de plusieurs niveaux de prix. À mesure que le market maker met à jour la courbe de prix, ce graphique évolue d’un slot à l’autre.

Source de l’image : github

Le point clé ici est que, en mettant à jour seulement quelques paramètres de la courbe de prix, le market maker peut à tout moment modifier la distribution des prix effectifs, sans avoir à modifier individuellement N ordres. C’est la proposition de valeur centrale du Prop AMM : il permet au market maker de fournir une liquidité dynamique et profonde avec une efficacité capitale et computationnelle supérieure.

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

Le Prop AMM est un système « activement géré », ce qui implique deux conditions clés :

1. Faible coût de mise à jour (cheap updates)

2. Priorité d’exécution (priority execution)

Sur Solana, ces deux aspects sont complémentaires : un coût de mise à jour faible signifie souvent que la mise à jour obtient la priorité d’exécution.

Pourquoi les market makers ont-ils besoin de ces deux éléments ? D’abord, ils mettent à jour la courbe de prix en fonction des variations de leur inventaire ou de l’indice de prix de l’actif (par exemple, le prix sur un exchange centralisé), à la vitesse de la blockchain. Sur une chaîne à haute fréquence comme Solana, si le coût de mise à jour est trop élevé, il est difficile de procéder à des ajustements fréquents.

Ensuite, si le market maker ne peut pas placer ses mises à jour en haut du bloc, ses anciennes cotations seront captées par des arbitragistes, entraînant des pertes inévitables. Sans ces deux caractéristiques, le market maker ne peut pas opérer efficacement et les utilisateurs obtiennent de moins bons prix.

Par exemple, sur Solana, le Prop AMM HumidiFi met à jour ses cotations jusqu’à 74 fois par seconde selon les données de @SliceAnalytics.

Les utilisateurs d’EVM pourraient se demander : « Un slot Solana dure environ 400 ms, comment un Prop AMM peut-il mettre à jour les prix plusieurs fois dans un seul 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 généralement exécutées dans l’ordre après qu’un bloc complet a été proposé et finalisé. Les mises à jour envoyées au milieu ne prennent effet qu’au bloc suivant.

· Solana : Le validateur leader ne patiente pas pour un bloc complet, mais diffuse continuellement les transactions en petits paquets (appelés « shreds ») sur le réseau. Un slot peut contenir plusieurs échanges, mais la mise à jour de prix du shred #1 affecte le swap #1, celle du shred #2 affecte le swap #2, etc.

Note : Les Flashblocks sont similaires aux shreds de Solana. Selon la présentation de @Ashwinningg d’Anza Labs à la conférence CBER, chaque slot de 400 ms peut contenir jusqu’à 32 000 shreds, soit 80 shreds par milliseconde. Reste à savoir si les Flashblocks de 200 ms sont suffisamment rapides pour répondre aux besoins des market makers, comparé à l’architecture continue de Solana.

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

D’abord, bien que l’implémentation des Prop AMMs sur Solana soit une boîte noire, il existe des bibliothèques comme Pinocchio qui permettent d’optimiser la consommation de Compute Units (CU) lors de l’écriture de programmes Solana. Le blog de Helius l’explique bien : grâce à cette bibliothèque, la consommation de CU d’un programme Solana peut passer d’environ 4 000 CU à seulement 100 CU.

Source de l’image : github

Ensuite, à un niveau plus global, Solana priorise les transactions ayant le meilleur ratio Fee / Compute Units (les Compute Units sont similaires au Gas de l’EVM), tout comme l’EVM.

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

· Sans Jito : Priority = (priority fee + base fee) / (1 + CU limit + signature CU + write lock CU)

En comparant les mises à jour de Prop AMM et les swaps Jupiter en termes de Compute Units, on voit que les mises à jour sont extrêmement bon marché, avec un ratio de 1:1000.

Mise à jour Prop AMM : Une simple mise à jour de courbe coûte très peu. Celle de Wintermute descend à 109 CU, pour un coût total de seulement 0.000007506 SOL

Jupiter Swap : Un swap routé via Jupiter peut atteindre ~100 000 CU, pour un coût total de 0.000005 SOL

En raison de cet écart énorme, les market makers n’ont qu’à payer des frais minimes pour les transactions de mise à jour, ce qui leur permet d’obtenir un ratio Fee/CU bien supérieur à celui des swaps, garantissant ainsi que leurs mises à jour sont exécutées en haut du bloc et les protégeant contre l’arbitrage.

Pourquoi les Prop AMMs ne sont-ils pas encore déployés sur EVM ?

Supposons que la mise à jour d’un Prop AMM implique l’écriture de variables déterminant la courbe de prix de la paire de trading. Bien que le code des Prop AMMs sur Solana soit une « boîte noire » (les market makers souhaitent garder leur stratégie secrète), nous pouvons utiliser cette hypothèse pour comprendre comment Obric implémente un Prop AMM sur Sui : les variables déterminant la cotation sont écrites dans le smart contract via une fonction update.

Merci à @markoggwp pour la découverte !

En partant de cette hypothèse, on constate que l’architecture EVM présente des obstacles majeurs qui rendent le modèle Prop AMM de Solana inapplicable sur EVM.

Rappelons que sur les blockchains Layer 2 OP-Stack (comme Base et Unichain), les transactions sont triées par priorité de frais par gas (comme Solana trie par Fee / CU).

Sur EVM, les opérations d’écriture consomment énormément de gas. Comparé à Solana, écrire une valeur via l’opcode SSTORE sur EVM coûte énormément :

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

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

· Swap AMM typique : ~200 000–300 000 gas

Note : Le Gas sur EVM est similaire aux Compute Units sur Solana. Les chiffres de gas SSTORE ci-dessus supposent une seule écriture par transaction (écriture froide), ce qui est raisonnable car on n’envoie généralement pas plusieurs mises à jour dans une seule transaction.

Bien que la mise à jour reste moins chère qu’un swap, l’utilisation de gas n’est qu’environ 10 fois inférieure (une mise à jour peut impliquer plusieurs SSTORE), alors que sur Solana, ce ratio est d’environ 1000 fois.

Cela conduit à deux conclusions qui rendent le modèle Prop AMM de Solana plus risqué sur EVM :

1. La forte consommation de gas rend difficile la garantie de la priorité des mises à jour : des frais de priorité faibles ne permettent pas d’obtenir un ratio élevé de frais/gas. Pour garantir que la mise à jour ne soit pas front-runnée et soit placée en haut du bloc, il faut payer des frais de priorité plus élevés, ce qui augmente le coût.

2. Le risque d’arbitrage est plus élevé sur EVM, car le ratio gas de mise à jour/gas de swap n’est que de 1:10 sur EVM, contre 1:1000 sur Solana. Cela signifie qu’un arbitragiste n’a qu’à augmenter ses frais de priorité 10 fois pour front-run la mise à jour du market maker, alors qu’il faudrait 1000 fois sur Solana. Avec ce ratio plus faible, il est plus probable que des arbitragistes front-runnent les mises à jour de prix pour profiter de cotations obsolètes, car le coût est faible.

Certaines innovations (comme TSTORE de l’EIP-1153, pour le stockage temporaire) offrent une écriture à environ 100 gas, mais ce stockage est temporaire, valable uniquement dans une transaction, et ne peut pas être utilisé pour persister une mise à jour de prix pour les swaps ultérieurs (par exemple, pendant toute la durée d’un bloc).

Comment introduire les Prop AMMs sur EVM ?

Avant de répondre au « comment », répondons au « pourquoi » : les utilisateurs veulent toujours de meilleurs prix de transaction, c’est-à-dire des échanges plus avantageux. Les Prop AMMs sur Ethereum et Layer 2 peuvent offrir aux utilisateurs des cotations compétitives auparavant réservées à Solana ou aux exchanges centralisés.

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

· Protection par mise à jour en haut de bloc : Sur Solana, les mises à jour Prop AMM sont placées en haut du bloc, protégeant le market maker contre le front-running. Elles sont en haut car la consommation de Compute Units est très faible, ce qui permet d’obtenir un ratio élevé de frais/CU même avec des frais bas, surtout comparé aux swaps.

Alors, comment amener les mises à jour Prop AMM en haut de bloc sur une blockchain Layer 2 EVM ? Deux solutions : soit réduire le coût d’écriture, soit créer un canal prioritaire pour les mises à jour Prop AMM.

En raison du problème de croissance de l’état sur EVM, réduire le coût d’écriture n’est pas réaliste, car des SSTORE bon marché entraîneraient des attaques par spam d’état.

Nous proposons de créer un canal prioritaire pour les mises à jour Prop AMM. C’est la solution réalisable et le point central de cet article.

@MarkToda de l’équipe Uniswap a proposé une nouvelle méthode utilisant un smart contract de stockage global + une stratégie de block builder dédiée :

Voici comment cela fonctionne :

· Smart contract de stockage global : Déployer un smart contract simple servant de stockage clé-valeur public. Les market makers écrivent les paramètres de la courbe de prix dans ce contrat (par exemple set(ETH-USDC_CONCENTRATION, 4000)).

· Stratégie de block builder : C’est le composant clé off-chain. Le block builder identifie les transactions envoyées au contrat de stockage global, réserve les 5–10% de gas du début du bloc à ces transactions de mise à jour, et les trie par frais pour éviter le spam.

À noter : les transactions doivent être envoyées directement à l’adresse du stockage global, sinon leur position en haut de bloc n’est pas garantie.

Pour un exemple d’algorithme de construction de bloc personnalisé, voir rblib.

Intégration Prop AMM : Le smart contract Prop AMM du market maker lit les données de la courbe de prix depuis le contrat de stockage global lors d’un swap, afin de fournir une cotation.

Cette architecture résout intelligemment deux problèmes :

1. Protection : La stratégie du block builder crée un « fast lane » garantissant que toutes les mises à jour de prix sont exécutées avant les transactions dans le bloc, éliminant le risque de front-running.

2. Rentabilité : Les market makers n’ont plus à rivaliser avec tous les utilisateurs DeFi pour placer leurs transactions en haut du bloc via des gas price élevés, ils ne rivalisent que localement pour les mises à jour réservées en haut de bloc, réduisant considérablement les coûts.

Les transactions des utilisateurs seront exécutées selon la courbe de prix définie par la mise à jour initiale du market maker dans le même bloc, garantissant la fraîcheur et la sécurité des cotations. Ce modèle recrée sur EVM l’environnement de mises à jour peu coûteuses et hautement prioritaires de Solana, ouvrant la voie aux Prop AMMs sur EVM.

Cependant, ce modèle présente aussi quelques inconvénients, que je laisse à la discussion en fin d’article.

Conclusion

La viabilité des Prop AMMs dépend de la résolution d’un problème économique central : des mises à jour peu coûteuses et prioritaires pour éviter le front-running.

Bien que l’architecture EVM standard rende ces opérations coûteuses et risquées, de nouveaux designs proposent différentes solutions. En combinant un smart contract de stockage global on-chain et une stratégie de block builder off-chain, il est possible de créer un « fast lane » dédié, garantissant l’exécution des mises à jour en haut de bloc et établissant un marché local et contrôlé des frais. Cela rend non seulement les Prop AMMs réalisables sur EVM, mais pourrait aussi transformer toute la DeFi EVM dépendant de mises à jour d’oracles en haut de bloc.

Questions ouvertes

· La vitesse des Flashblocks de 200 ms sur EVM est-elle suffisante pour rivaliser avec l’architecture continue de Solana pour les Prop AMMs ?

· Sur Solana, la majorité du trafic AMM provient de l’agrégateur unique Jupiter, qui fournit un SDK facilitant l’intégration des AMMs. Mais sur Layer 2 EVM, le trafic est réparti entre plusieurs agrégateurs sans SDK public. Cela pose-t-il un défi pour les Prop AMMs ?

· Les mises à jour Prop AMM sur Solana ne consomment qu’environ 100 CU. Comment cela est-il implémenté ?

· Le modèle fast lane ne garantit que les mises à jour en haut de bloc. Si plusieurs swaps ont lieu dans un même Flashblock, comment le market maker met-il à jour les prix entre ces swaps ?

· Peut-on écrire des programmes EVM optimisés en Yul ou Huff, similaires à l’optimisation Pinocchio sur Solana ?

· Comment comparer Prop AMM et RFQ ?

· Comment empêcher un market maker de proposer une cotation avantageuse au bloc N pour attirer l’utilisateur, puis de la mettre à jour en une mauvaise cotation au bloc N+1 ? Comment Jupiter s’en prémunit-il ?

· La fonctionnalité Ultra Signaling de Jupiter Ultra V3 permet aux Prop AMMs de distinguer le trafic nuisible du trafic bénin et de proposer des cotations plus serrées. Quelle est l’importance de telles fonctionnalités d’agrégateur pour les Prop AMMs sur EVM ?

Lien vers l’article original