Pourquoi Solana regorge de Prop AMM, mais pas l'EVM ?

Titre original de l'article : Must-Watch dApps After Monad Mainnet Launch

Auteur original de l'article : @0xOptimus

Traduction de l'article original : Dingdang, Odaily Planet Daily

Les Prop AMM ont rapidement capturé 40 % du volume trading total de Solana. Pourquoi n'ont-ils pas encore fait leur apparition sur l'EVM ?

Les Proprietary Automated Market Makers (Prop AMM) deviennent rapidement la force dominante de l'écosystème DeFi de Solana, contribuant actuellement à plus de 40 % du volume trading sur les paires majeures. Ces lieux de liquidité gérés par des market makers professionnels peuvent offrir une liquidité profonde et des prix plus compétitifs. La raison principale est qu'ils réduisent considérablement le risque pour les market makers d'être exploités par des "stale quotes" pour mener des arbitrages de front-running.

Source de l'image : dune.com

Cependant, leur succès a été presque entièrement limité à Solana. Même sur des réseaux Layer 2 rapides et peu coûteux comme Base ou Optimism, la présence de Prop AMM dans l'écosystème EVM est rare. Pourquoi ne se sont-ils pas implantés sur l'EVM ?

Cet article explore principalement trois questions : ce que sont les Prop AMM, les barrières techniques et économiques auxquelles ils sont confrontés sur la chaîne EVM, et les nouvelles architectures prometteuses qui pourraient éventuellement les placer à l'avant-garde de la DeFi sur EVM.

Que sont les Prop AMM ?

Les Prop AMM sont un type d'automated market maker où un seul market maker professionnel gère activement la liquidité et la tarification, plutôt que d'avoir des fonds fournis passivement par le public comme dans les AMM traditionnels.

Les AMM traditionnels (tels qu'Uniswap v2) utilisent généralement la formule x * y = k pour déterminer le prix, où x et y représentent les quantités des deux actifs dans le pool, et k est une constante. Dans les Prop AMM, la formule de tarification n'est pas fixe mais est fréquemment mise à jour (souvent plusieurs fois par seconde). Étant donné que les mécanismes internes de la plupart des Prop AMM sont considérés comme une "boîte noire", le monde extérieur ne connaît pas l'algorithme exact qu'ils utilisent. Cependant, le code du smart contract Prop AMM sur la chaîne Sui d'Obric est public (grâce à la découverte de @markoggwp), où l'invariant k dépend des variables internes mult_x, mult_y et concentration. L'image ci-dessous montre comment le market maker met continuellement à jour ces variables.

Un point qui nécessite des éclaircissements est que la formule sur le côté gauche de la courbe de tarification d'Obric est plus complexe qu'un simple x*y. Cependant, la clé pour comprendre le Prop AMM est qu'il est toujours égal à un invariant variable k, et les fournisseurs de liquidité mettent continuellement à jour ce k pour ajuster la courbe de prix.

Revue : Comment l'AMM détermine-t-il les prix ?

Dans cet article, nous mentionnerons le concept de "courbe de prix" à plusieurs reprises. La courbe de prix détermine le prix que les utilisateurs doivent payer lors de transactions utilisant un AMM et est la partie que les fournisseurs de liquidité mettent continuellement à jour dans le Prop AMM. Pour mieux comprendre cela, nous pouvons d'abord passer en revue le mécanisme de tarification d'un AMM traditionnel.

Prenons l'exemple du pool WETH-USDC sur Uniswap v2 (en supposant l'absence de frais). Le prix est passivement déterminé par la formule x * y = k. En supposant qu'il y ait 100 WETH et 400 000 USDC dans le pool, le point actuel de la courbe est x = 100, y = 400 000, correspondant à un prix initial de 400 000 / 100 = 4 000 USDC/WETH. Cela donne une constante k = 100 * 400 000 = 40 000 000.

Si un trader souhaite acheter 1 WETH, il doit ajouter de l'USDC au pool, réduisant 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. Cela signifie que le trader a payé environ 4 040,40 USDC pour 1 WETH, légèrement plus élevé que le prix initial. Ce phénomène est connu sous le nom de "glissement de prix" (price slippage). C'est pourquoi x*y=k est appelé une "courbe de prix" : tout prix négociable doit tomber sur cette courbe.

Pourquoi les fournisseurs de liquidité choisissent-ils la conception AMM plutôt qu'un carnet d'ordres centralisé (CLOB) ?

Expliquons pourquoi les fournisseurs de liquidité voudraient utiliser la conception AMM pour fournir de la liquidité. Imaginez que vous soyez un market maker cotant sur un carnet d'ordres centralisé (CLOB) on-chain. Si vous souhaitez mettre à jour votre cotation, vous devriez annuler et remplacer des milliers d'ordres limités. Si vous avez N ordres, le coût de mise à jour est une opération O(N), ce qui est lent et coûteux on-chain.

Mais que se passerait-il si vous pouviez représenter toutes les cotations avec une courbe mathématique ? En mettant simplement à jour quelques paramètres clés définissant cette courbe, vous pouvez transformer une opération O(N) en une complexité constante O(1).

Pour démontrer visuellement comment la "courbe de prix" correspond à différentes plages de prix effectives, nous pouvons nous référer à SolFi créé par Ellipsis Labs—un Prop AMM basé sur Solana. Bien que sa courbe de prix spécifique soit inconnue et cachée, Ghostlabs a créé un graphique montrant le prix effectif lors de l'échange de quantités variables de SOL contre de l'USDC au sein d'un certain slot Solana (période de bloc). Chaque ligne représente un pool WSOL/USDC différent, illustrant que plusieurs niveaux de prix peuvent coexister. À mesure que le fournisseur de liquidité met à jour la courbe de prix, ce graphique de prix effectif changera également entre les différents slots.

Source de l'image : GitHub

La clé ici est qu'en mettant à jour seulement quelques paramètres de courbe de prix, les fournisseurs de liquidité peuvent modifier dynamiquement la distribution des prix effectifs à tout moment sans avoir à modifier chacun des N ordres individuellement. C'est précisément la proposition de valeur fondamentale du Prop AMM : il permet aux fournisseurs de liquidité d'offrir une liquidité dynamique et profonde avec une efficacité de capital et de calcul plus élevée.

Pourquoi l'architecture de Solana est-elle idéale pour le Prop AMM ?

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

1. Faibles coûts de mise à jour

2. Exécution prioritaire

Sur Solana, ces deux aspects sont entrelacés : Les mises à jour à faible coût signifient souvent que les mises à jour peuvent avoir une exécution prioritaire.

Mais pourquoi les fournisseurs de liquidité ont-ils besoin de ces deux points ? Premièrement, ils mettront continuellement à jour la courbe de prix en fonction des changements d'inventaire ou des fluctuations des prix des indices d'actifs (par exemple, les prix des plateformes crypto centralisées) à la vitesse de la blockchain. Sur une chaîne à haute fréquence comme Solana, si les coûts de mise à jour sont trop élevés, atteindre des ajustements à haute fréquence serait difficile.

Deuxièmement, si un fournisseur de liquidité ne peut pas faire inclure sa mise à jour en haut d'un bloc, son ancienne cotation sera "front-run" par des arbitragistes, entraînant une perte inévitable. Sans ces deux fonctionnalités, les fournisseurs de liquidité ne peuvent pas fonctionner efficacement, et les utilisateurs recevraient de moins bons prix de transaction.

En utilisant l'exemple du Prop AMM HumidiFi sur Solana, selon les données de @SliceAnalytics, le fournisseur de liquidité met à jour sa cotation jusqu'à 74 fois par seconde.

Les acteurs venant de l'EVM peuvent demander : "Le slot de Solana est d'environ 400ms, comment le Prop AMM peut-il mettre à jour le prix plusieurs fois au sein d'un seul slot ?"

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

· EVM : Les transactions s'exécutent généralement de manière séquentielle après qu'un bloc complet est proposé et finalement confirmé. Cela signifie que les mises à jour envoyées au milieu prennent effet dans le bloc suivant.

· Solana : Les nœuds validateurs leaders n'attendent pas un bloc complet ; au lieu de cela, ils décomposent les transactions en petits paquets de données (appelés "shreds") et les diffusent continuellement sur le réseau. Au sein d'un slot, il peut y avoir plusieurs échanges, mais la mise à jour de prix dans le shred #1 affecte le swap #1, et la mise à jour de prix dans le shred #2 affecte le swap #2.

Note : Les Flashblocks sont similaires aux shreds de Solana. Selon @Ashwinningg d'Anza Labs lors de la conférence CBER, la limite du slot de 32 000 shreds toutes les 400ms équivaut à 80 shreds par milliseconde. La question de savoir si les Flashblocks de 200ms sont assez rapides pour répondre aux exigences des fournisseurs de liquidité reste ouverte par rapport à l'architecture continue de Solana.

Alors, pourquoi les mises à jour sur Solana sont-elles si bon marché ? Et qu'est-ce qui conduit à leur exécution prioritaire ?

Premièrement, bien que l'implémentation du Prop AMM sur Solana soit une boîte noire, il existe une bibliothèque comme Pinocchio qui optimise la façon dont les CU sont écrits dans les programmes Solana. Le blog de Helius fournit une merveilleuse explication. Avec cette bibliothèque, la consommation de CU des programmes Solana peut être réduite d'environ 4000 CU à environ 100 CU.

Source de l'image : github

Regardons maintenant la deuxième partie. À un niveau supérieur, Solana priorise les transactions en sélectionnant celles avec le ratio Frais / Compute Units le plus élevé (les Compute Units sont similaires au gas de l'EVM), similaire à l'EVM.

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

· Sinon : Priorité = (Tip + Frais de base) / (1 + Limite CU + Signature CU + Write Lock CU)

En comparant les Compute Units d'une mise à jour Prop AMM à un Jupiter Swap, il est évident que la mise à jour est extrêmement bon marché, avec un ratio de 1:1000.

Mise à jour Prop AMM : La simple mise à jour de courbe est très peu coûteuse. La mise à jour de Wintermute est aussi basse que 109 CU, avec un coût total de seulement 0,000007506 SOL

Jupiter Swap : Un swap via la route Jupiter peut atteindre ~100 000 CU, avec un coût total de 0,000005 SOL

En raison de cette différence significative, les fournisseurs de liquidité n'ont besoin de payer qu'un frais minime pour les transactions de mise à jour, atteignant un ratio Frais/CU beaucoup plus élevé que les échanges, garantissant que les mises à jour sont exécutées en haut du bloc, se protégeant ainsi des attaques d'arbitrage.

Pourquoi le Prop AMM n'a-t-il pas encore atterri sur l'EVM ?

En supposant qu'une mise à jour Prop AMM implique l'écriture dans une variable qui détermine la courbe de prix de la paire d'actifs. Bien que le code du Prop AMM sur Solana soit une "boîte noire", les fournisseurs de liquidité souhaitant garder leurs stratégies confidentielles, nous pouvons utiliser cette hypothèse pour comprendre comment Obric a implémenté le Prop AMM sur Sui : la variable déterminant le prix de la paire d'actifs est écrite dans le smart contract via une fonction de mise à jour.

Merci à @markoggwp pour la découverte !

Avec cette hypothèse, nous avons trouvé une barrière significative dans l'architecture de l'EVM qui rend le modèle Prop AMM de Solana irréalisable sur l'EVM.

Rappelons que sur les blockchains Layer 2 OP-Stack (telles que Base et Unichain), les transactions sont priorisées en fonction des frais par Gas (similaire au tri Frais/CU de Solana).

Sur l'EVM, le coût en Gas des opérations d'écriture est extrêmement élevé. Comparé aux mises à jour de Solana, le coût de l'écriture d'une valeur sur l'EVM via l'opcode SSTORE est stupéfiant :

· 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 l'EVM est similaire aux Computational Units (CU) sur Solana. Les chiffres de gas SSTORE ci-dessus supposent que chaque transaction n'a qu'une seule écriture (écriture à froid), ce qui est raisonnable car plusieurs mises à jour ne sont généralement pas envoyées au sein d'une seule transaction.

Bien que les mises à jour soient toujours moins chères que les swaps, l'efficacité du gas n'est que d'environ 10x (les mises à jour peuvent impliquer plusieurs SSTORE), alors que sur Solana, ce ratio est d'environ 1000x.

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

1. Les coûts élevés en Gas rendent difficile la garantie de la priorité de mise à jour : Des frais de gas plus bas ne peuvent pas garantir un ratio frais/Gas élevé. Pour garantir que les mises à jour ne soient pas front-run et soient placées en haut d'un bloc, des frais de gas plus élevés sont nécessaires, augmentant les coûts.

2. Risque d'arbitrage plus élevé sur l'EVM : Le ratio Gas de mise à jour sur Gas de swap sur l'EVM n'est que de 1:10, alors que sur Solana, il est de 1:1000. Cela signifie que les arbitragistes n'ont besoin d'augmenter les frais que de 10x pour front-run la mise à jour d'un fournisseur de liquidité, comparé à 1000x sur Solana. Dans ce scénario de ratio plus faible, les arbitragistes sont plus susceptibles de front-run les mises à jour de prix pour capturer des "stale quotes" en raison du faible coût.

Certaines innovations (telles que le TSTORE de l'EIP-1153 pour le stockage temporaire) offrent un coût d'écriture d'environ 100 gas, mais ce stockage est éphémère, valide uniquement au sein d'une seule transaction et ne peut pas être utilisé pour persister des mises à jour de prix pour une utilisation ultérieure dans le trading de dérivés (par exemple, sur toute une période de bloc).

Comment introduire le Prop AMM sur l'EVM ?

Avant de répondre, abordons le "pourquoi le faire" : Les utilisateurs veulent toujours de meilleures cotations de transaction, ce qui signifie plus pour leur argent. Le Prop AMM d'Ethereum et des Layer 2 peut fournir aux utilisateurs des cotations compétitives qui n'étaient auparavant disponibles que sur Solana ou les plateformes crypto centralisées.

Pour rendre le Prop AMM réalisable sur l'EVM, passons en revue l'une des raisons de son succès sur Solana :

· Protection de mise à jour en haut de bloc : Sur Solana, les mises à jour Prop AMM sont en haut de bloc pour protéger les fournisseurs de liquidité du front-running. Les mises à jour en haut de bloc sont possibles car le coût en unité de calcul est minime, permettant même à des frais bas d'atteindre un ratio frais/CU élevé, surtout par rapport aux transactions de dérivés.

Alors, comment pouvons-nous introduire des mises à jour Prop AMM en haut de bloc sur une blockchain EVM Layer 2 ? Il existe deux approches : 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 de l'EVM, l'approche de réduction du coût d'écriture est moins viable, car des SSTORE bon marché conduiraient à des attaques de gonflement de l'état.

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

@MarkToda d'Uniswap a proposé une nouvelle approche, tirant parti d'une Stratégie de Smart Contract de Stockage Global + Constructeur de Bloc Dédié :

Voici comment cela fonctionne :

· Contrat de stockage global : Déployez un simple smart contract comme magasin clé-valeur public. Les fournisseurs de liquidité écrivent les paramètres de la courbe de prix dans ce contrat (par exemple, set(ETH-USDC_CONCENTRATION, 4000)).

· Stratégie de constructeur : C'est un composant clé off-chain. Le constructeur de bloc identifie les transactions envoyées au contrat de stockage global, alloue 5 à 10 % du Gas du bloc à ces transactions de mise à jour, les priorise par frais et les trie pour empêcher les transactions de spam.

Veuillez noter : Les transactions doivent être envoyées directement à l'adresse de stockage global pour garantir le placement en haut du bloc.

Des exemples d'algorithmes de construction de bloc personnalisés peuvent être trouvés dans rblib.

Intégration Prop AMM : Le contrat Prop AMM des fournisseurs de liquidité lit les données de la courbe de prix à partir du contrat de stockage global lors des swaps pour fournir des cotations.

Cette architecture résout habilement deux problèmes :

1. Protection : La stratégie de constructeur crée une "voie rapide" pour garantir que toutes les mises à jour de prix dans le bloc sont exécutées avant les transactions, éliminant le risque de front-running.

2. Efficacité des coûts : Les fournisseurs de liquidité ne sont plus en concurrence avec tous les utilisateurs DeFi pour des prix de Gas élevés afin d'entrer en haut du bloc ; au lieu de cela, ils n'ont besoin d'être en concurrence que pour le haut du bloc réservé aux transactions de mise à jour sur le marché local des frais, réduisant considérablement les coûts.

Les transactions des utilisateurs s'exécuteront en fonction de la courbe de prix définie par le fournisseur de liquidité au début du même bloc, garantissant la fraîcheur et la sécurité des cotations. Ce modèle reproduit l'environnement de mise à jour à faible coût et haute priorité sur Solana dans l'EVM, ouvrant la voie au Prop AMM sur l'EVM.

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

Conclusion

La faisabilité du Prop AMM dépend de la résolution d'un problème économique fondamental : une exécution bon marché et prioritaire pour empêcher le front-running.

Bien que l'architecture EVM standard rende de telles opérations coûteuses et risquées, de nouvelles conceptions offrent différentes approches pour résoudre ce problème. En combinant des smart contracts de stockage global on-chain et une stratégie de constructeur off-chain dans la nouvelle conception, une "voie rapide" dédiée peut être créée pour garantir l'exécution des mises à jour en haut de bloc, tout en établissant un marché de frais local et contrôlé. Cela rend non seulement le Prop AMM viable sur l'EVM, mais pourrait également révolutionner toute la DeFi sur EVM reposant sur des mises à jour d'oracle en haut de bloc.

Questions ouvertes

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

· Sur Solana, la plupart du trafic AMM provient d'un seul agrégateur appelé Jupiter, qui fournit un SDK pour une intégration AMM facile. Cependant, sur l'EVM Layer 2, le trafic est dispersé entre plusieurs agrégateurs sans SDK public. Cela pose-t-il un défi pour le Prop AMM ?

· Sur Solana, les mises à jour Prop AMM ne consomment qu'environ 100 CU. Quel est le mécanisme d'implémentation derrière cette efficacité ?

· Le modèle de chemin rapide ne garantit que les mises à jour en haut d'un bloc. S'il y a plusieurs échanges au sein d'un Flashblock, comment les fournisseurs de liquidité mettent-ils à jour les prix entre ces échanges ?

· Est-il possible d'écrire des programmes EVM optimisés en utilisant des langages comme Yul ou Huff, similaires à l'approche d'optimisation Pinocchio de Solana ?

· Comment le Prop AMM se compare-t-il au RFQ ?

· Comment pouvons-nous empêcher les fournisseurs de liquidité d'offrir des cotations compétitives dans le bloc N pour attirer les utilisateurs, puis de passer à des cotations non compétitives dans le bloc N+1 ? Comment Jupiter atténue-t-il ce risque ?

· La fonctionnalité Ultra Signaling de Jupiter Ultra V3 permet au Prop AMM de différencier le trafic nuisible du trafic bénin, fournissant des cotations plus serrées. À quel point ces fonctionnalités d'agrégateur sont-elles cruciales pour le Prop AMM sur EVM ?

Lien vers le post original