Perché su Solana ci sono tanti Prop AMM, mentre su EVM sono ancora assenti?

Titolo originale: Must-Watch dApps After Monad Mainnet Launch

Autore originale: Optimus, fondatore di Waterloo Blockchain

Traduzione originale: Dingdang, Odaily

I Prop AMM hanno rapidamente conquistato il 40% di tutto il volume di trading su Solana. Perché non sono ancora apparsi su EVM?

I Market Maker Automatici Proprietari (Proprietary AMMs, abbreviato Prop AMM) stanno rapidamente diventando una forza dominante nell’ecosistema DeFi di Solana, contribuendo attualmente a oltre il 40% del volume di trading delle principali coppie. Questi luoghi di liquidità gestiti da market maker professionisti possono offrire liquidità profonda e prezzi più competitivi, principalmente perché riducono significativamente il rischio che i market maker vengano sfruttati tramite “quotazioni obsolete” (stale quotes) per front-running e arbitraggio.

Fonte immagine: dune.com

Tuttavia, il loro successo è quasi interamente limitato a Solana. Anche su reti Layer 2 veloci e a basso costo come Base o Optimism, i Prop AMM sono ancora rari nell’ecosistema EVM. Perché non hanno messo radici su EVM?

Questo articolo esplora principalmente tre domande: cosa sono i Prop AMM, quali ostacoli tecnici ed economici affrontano sulle chain EVM e quali nuove architetture promettenti potrebbero portarli all’avanguardia della DeFi EVM.

Cosa sono i Prop AMM?

I Prop AMM sono una tipologia di market maker automatici in cui la liquidità e la determinazione dei prezzi sono gestite attivamente da un singolo market maker professionista, invece che da fornitori di liquidità passivi come nei tradizionali AMM.

Gli AMM tradizionali (come Uniswap v2) di solito utilizzano la formula x * y = k per determinare il prezzo, dove x e y rappresentano rispettivamente la quantità delle due asset nel pool e k è una costante. Nei Prop AMM, invece, la formula di determinazione del prezzo non è fissa, ma viene aggiornata ad alta frequenza (di solito più volte al secondo). Poiché la maggior parte dei Prop AMM utilizza meccanismi interni “black box”, non si conoscono gli algoritmi esatti utilizzati. Tuttavia, il codice smart contract del Prop AMM di Obric su Sui è pubblico (grazie alla scoperta di @markoggwp), e la sua costante k dipende dalle variabili interne mult_x, mult_y e concentration. L’immagine seguente mostra come il market maker aggiorna continuamente queste variabili.

È importante chiarire che: la formula sul lato sinistro della curva di prezzo di Obric è più complessa di un semplice x*y, ma la chiave per comprendere i Prop AMM è che essa equivale sempre a una costante k variabile, che il market maker aggiorna costantemente per regolare la curva dei prezzi.

Ripasso: come determinano il prezzo gli AMM?

In questo articolo, menzioneremo spesso il concetto di “curva dei prezzi”. La curva dei prezzi determina il prezzo che l’utente deve pagare quando scambia tramite un AMM, ed è la parte che il market maker aggiorna costantemente nei Prop AMM. Per comprenderlo meglio, possiamo ripassare il metodo di determinazione del prezzo nei tradizionali AMM.

Prendiamo come esempio il pool WETH-USDC su Uniswap v2 (supponendo nessuna commissione). Il prezzo è determinato passivamente dalla formula x * y = k. Supponiamo che il pool contenga 100 WETH e 400.000 USDC, il punto sulla curva è x = 100, y = 400.000, il prezzo iniziale è 400.000 / 100 = 4.000 USDC/WETH. Da qui, la costante k = 100 * 400.000 = 40.000.000.

Se un trader vuole acquistare 1 WETH, deve aggiungere USDC al pool, facendo scendere il WETH a 99. Per mantenere il prodotto costante k, il nuovo punto (x, y) deve rimanere sulla curva, quindi y deve diventare 40.000.000 / 99 ≈ 404.040,40. In altre parole, il trader paga circa 4.040,40 USDC per 1 WETH, leggermente più del prezzo iniziale. Questo fenomeno si chiama “slippage”. Ecco perché x*y=k viene chiamata “curva dei prezzi”: ogni prezzo negoziabile deve trovarsi su questa curva.

Perché i market maker scelgono il design AMM invece del Centralized Limit Order Book (CLOB)?

Spieghiamo perché i market maker vogliono utilizzare il design AMM per fare market making. Immagina di essere un market maker che quota su un CLOB on-chain. Per aggiornare le tue quotazioni, devi cancellare e sostituire migliaia di ordini limite. Se hai N ordini, l’aggiornamento è un’operazione di complessità O(N), lenta e costosa on-chain.

Ma se potessi rappresentare tutte le quotazioni con una curva matematica? Ti basterebbe aggiornare pochi parametri che definiscono la curva, trasformando un’operazione O(N) in una di complessità costante O(1).

Per mostrare visivamente come la “curva dei prezzi” corrisponda a diverse fasce di prezzo efficaci, possiamo fare riferimento a SolFi di Ellipsis Labs, un Prop AMM su Solana. Sebbene la curva dei prezzi specifica sia sconosciuta e nascosta, Ghostlabs ha disegnato un grafico che mostra, in uno slot Solana, il prezzo effettivo per diversi importi di SOL scambiati con USDC. Ogni linea rappresenta un pool WSOL/USDC diverso, mostrando che possono coesistere più livelli di prezzo. Man mano che il market maker aggiorna la curva dei prezzi, anche questo grafico cambia tra gli slot.

Fonte immagine: github

Il punto chiave qui è che, aggiornando solo pochi parametri della curva dei prezzi, il market maker può cambiare la distribuzione dei prezzi efficaci in qualsiasi momento, senza dover modificare singolarmente N ordini. Questo è il valore fondamentale dei Prop AMM: consentono ai market maker di fornire liquidità dinamica e profonda con maggiore efficienza di capitale e computazionale.

Perché l’architettura di Solana è ideale per i Prop AMM?

I Prop AMM sono sistemi “attivamente gestiti”, il che significa che richiedono due condizioni chiave:

1. Bassi costi di aggiornamento (cheap updates)

2. Esecuzione prioritaria (priority execution)

Su Solana, questi due aspetti si rafforzano a vicenda: aggiornamenti a basso costo spesso significano che l’aggiornamento ottiene priorità di esecuzione.

Perché i market maker hanno bisogno di questi due aspetti? Innanzitutto, aggiornano costantemente la curva dei prezzi in base alle variazioni dell’inventario o del prezzo dell’asset (ad esempio il prezzo su exchange centralizzati), alla velocità della blockchain. Su chain ad alta frequenza come Solana, se il costo di aggiornamento è troppo alto, è difficile effettuare aggiustamenti frequenti.

Inoltre, se il market maker non riesce a far sì che l’aggiornamento sia in cima al blocco, le sue vecchie quotazioni verranno sfruttate dagli arbitraggisti, causando perdite inevitabili. Senza queste due caratteristiche, il market maker non può operare in modo efficiente e gli utenti otterranno prezzi peggiori.

Prendiamo come esempio HumidiFi, un Prop AMM su Solana: secondo i dati di @SliceAnalytics, questo market maker aggiorna le quotazioni fino a 74 volte al secondo.

Chi proviene dall’EVM potrebbe chiedersi: “Uno slot Solana dura circa 400ms, come può un Prop AMM aggiornare il prezzo più volte in un singolo slot?”

La risposta sta nell’architettura continua di Solana, che è fondamentalmente diversa dal modello a blocchi discreti di EVM.

· EVM: Le transazioni vengono generalmente eseguite in ordine solo dopo che un intero blocco viene proposto e finalizzato. Gli aggiornamenti inviati nel frattempo diventano effettivi solo nel blocco successivo.

· Solana: Il nodo leader non aspetta un blocco completo, ma suddivide le transazioni in piccoli pacchetti (“shred”) e li trasmette continuamente alla rete. In uno slot possono esserci più swap, ma l’aggiornamento del prezzo in shred #1 influenza swap #1, quello in shred #2 influenza swap #2.

Nota: I Flashblocks sono simili agli shred di Solana. Secondo la presentazione di @Ashwinningg di Anza Labs alla conferenza CBER, il limite per slot di 400ms è di 32.000 shred, ovvero 80 shred per millisecondo. Se i Flashblocks da 200ms siano abbastanza veloci per i market maker rispetto all’architettura continua di Solana resta una questione aperta.

Perché gli aggiornamenti su Solana sono così economici? E come portano all’esecuzione prioritaria?

Innanzitutto, anche se l’implementazione dei Prop AMM su Solana è una black box, esistono librerie come Pinocchio che consentono di scrivere programmi Solana ottimizzati per il consumo di CU. Il blog di Helius lo spiega bene: grazie a questa libreria, il consumo di CU di un programma Solana può scendere da circa 4000 CU a circa 100 CU.

Fonte immagine: github

In secondo luogo, a un livello superiore, Solana ordina le transazioni in base al rapporto Fee / Compute Units più alto (le Compute Units sono simili al Gas di EVM), proprio come EVM.

· In particolare, se si usa Jito, la formula è Jito Tip / Compute Units

· Se non si usa: Priority = (priority fee + base fee) / (1 + CU limit + signature CU + write lock CU)

Confrontando le Compute Units degli aggiornamenti Prop AMM e degli swap Jupiter, si vede che gli aggiornamenti sono estremamente economici, con un rapporto di 1:1000.

Aggiornamento Prop AMM: Un semplice aggiornamento di curva è molto economico. L’aggiornamento di Wintermute arriva a 109 CU, con un costo totale di soli 0,000007506 SOL

Jupiter Swap: Uno swap tramite il router Jupiter può arrivare a ~100.000 CU, con un costo totale di 0,000005 SOL

Grazie a questa enorme differenza, i market maker possono pagare una fee minima per l’aggiornamento, ottenendo un rapporto Fee/CU molto più alto rispetto agli swap, garantendo così che l’aggiornamento venga eseguito in cima al blocco e proteggendosi dagli attacchi di arbitraggio.

Perché i Prop AMM non sono ancora arrivati su EVM?

Supponiamo che l’aggiornamento di un Prop AMM comporti la scrittura delle variabili che determinano la curva dei prezzi della coppia. Anche se il codice dei Prop AMM su Solana è una “black box” e i market maker vogliono mantenere segrete le loro strategie, possiamo usare questa ipotesi per capire come Obric implementa i Prop AMM su Sui: le variabili che determinano la quotazione vengono scritte nello smart contract tramite una funzione update.

Grazie a @markoggwp per la scoperta!

Con questa ipotesi, scopriamo che l’architettura EVM presenta ostacoli significativi che rendono il modello Prop AMM di Solana impraticabile su EVM.

Ricordiamo che sulle blockchain Layer 2 OP-Stack (come Base e Unichain), le transazioni sono ordinate per priority fee per gas (simile a Solana che ordina per Fee / CU).

Sull’EVM, le operazioni di scrittura consumano molto gas. Rispetto agli aggiornamenti su Solana, il costo di scrivere un valore tramite opcode SSTORE su EVM è sorprendente:

· SSTORE (0 → non 0): ~22.100 gas

· SSTORE (non 0 → non 0): ~5.000 gas

· Swap tipico AMM: ~200.000–300.000 gas

Nota: Il Gas su EVM è simile alle Compute Units su Solana. I numeri sopra per SSTORE assumono una sola scrittura per transazione (scrittura “fredda”), ragionevole perché di solito non si inviano più aggiornamenti in una sola transazione.

Anche se l’aggiornamento è ancora più economico dello swap, il rapporto di utilizzo del gas è solo circa 10 volte (l’aggiornamento può coinvolgere più SSTORE), mentre su Solana è circa 1000 volte.

Questo porta a due conclusioni che rendono il modello Prop AMM di Solana più rischioso su EVM:

1. L’alto consumo di gas rende difficile garantire la priorità dell’aggiornamento, poiché una priority fee bassa non può raggiungere un alto rapporto fee/gas. Per garantire che l’aggiornamento non venga front-runnato e sia in cima al blocco, serve una priority fee più alta, aumentando i costi.

2. Il rischio di arbitraggio su EVM è maggiore, perché il rapporto tra gas di aggiornamento e gas di swap è solo 1:10, mentre su Solana è 1:1000. Questo significa che un arbitraggista deve solo aumentare la priority fee di 10 volte per front-runnare l’aggiornamento del market maker, mentre su Solana dovrebbe aumentarla di 1000 volte. Con questo rapporto più basso, è più probabile che gli arbitraggisti front-runnino le quotazioni obsolete, dato il basso costo.

Alcune innovazioni (come EIP-1153 TSTORE, per storage temporaneo) offrono scritture a circa 100 gas, ma questo storage è temporaneo e valido solo per una singola transazione, quindi non può essere usato per rendere persistenti gli aggiornamenti di prezzo per swap successivi (ad esempio durante tutto il blocco).

Come portare i Prop AMM su EVM?

Prima di rispondere, rispondiamo al “perché farlo”: gli utenti vogliono sempre quotazioni migliori, cioè scambi più convenienti. I Prop AMM su Ethereum e Layer 2 possono offrire agli utenti quotazioni competitive che prima erano disponibili solo su Solana o sugli exchange centralizzati.

Per rendere i Prop AMM praticabili su EVM, ricordiamo uno dei motivi del loro successo su Solana:

· Aggiornamenti protetti in cima al blocco: su Solana, gli aggiornamenti Prop AMM sono in cima al blocco, proteggendo i market maker dal front-running. Gli aggiornamenti sono in cima perché consumano pochissime compute unit, quindi anche con fee basse ottengono un alto rapporto fee/CU, soprattutto rispetto agli swap.

Come portare gli aggiornamenti Prop AMM in cima al blocco su blockchain EVM Layer 2? Ci sono due modi: abbassare il costo di scrittura o creare un canale prioritario per gli aggiornamenti Prop AMM.

Poiché il problema della crescita dello stato su EVM rende poco praticabile abbassare il costo di scrittura (SSTORE economico porterebbe ad attacchi di spam dello stato),

proponiamo di creare un canale prioritario per gli aggiornamenti Prop AMM. Questa è la soluzione praticabile e il focus di questo articolo.

@MarkToda del team Uniswap ha proposto un nuovo metodo, che utilizza smart contract di storage globale + una strategia di block builder dedicata:

Funziona così:

· Smart contract di storage globale: Si distribuisce un semplice smart contract come storage pubblico chiave-valore. I market maker scrivono i parametri della curva dei prezzi in questo contratto (ad esempio set(ETH-USDC_CONCENTRATION, 4000)).

· Strategia del builder: Questo è il componente chiave off-chain. Il block builder riconosce le transazioni inviate allo storage globale, riserva il 5–10% del gas del blocco per queste transazioni di aggiornamento e le ordina per fee, prevenendo spam.

Nota: Le transazioni devono essere inviate direttamente all’indirizzo dello storage globale, altrimenti non si può garantire che siano in cima al blocco.

Un esempio di algoritmo di block building personalizzato è disponibile in rblib.

Integrazione Prop AMM: Il contratto Prop AMM del market maker legge i dati della curva dei prezzi dallo storage globale durante lo swap, fornendo la quotazione.

Questa architettura risolve abilmente due problemi:

1. Protezione: La strategia del builder crea un “canale veloce” che garantisce che tutti gli aggiornamenti dei prezzi vengano eseguiti prima delle transazioni di swap nel blocco, eliminando il rischio di front-running.

2. Efficienza dei costi: I market maker non devono più competere con tutti gli utenti DeFi per una posizione in cima al blocco tramite gas price elevati, ma solo nel mercato locale delle fee riservato agli aggiornamenti, riducendo notevolmente i costi.

Le transazioni degli utenti verranno eseguite in base alla curva dei prezzi impostata dal market maker all’inizio dello stesso blocco, garantendo la freschezza e la sicurezza della quotazione. Questo modello ricrea su EVM l’ambiente di aggiornamenti a basso costo e alta priorità di Solana, aprendo la strada ai Prop AMM su EVM.

Tuttavia, questo modello presenta anche alcuni svantaggi, che lascio in fondo all’articolo per la discussione.

Conclusione

La fattibilità dei Prop AMM dipende dalla risoluzione di un problema economico centrale: aggiornamenti economici e prioritari per prevenire il front-running.

Sebbene l’architettura EVM standard renda queste operazioni costose e rischiose, i nuovi design offrono approcci diversi per risolvere il problema. Combinando smart contract di storage globale on-chain e strategie di builder off-chain, si può creare un “canale veloce” dedicato che garantisce l’esecuzione degli aggiornamenti in cima al blocco e stabilisce un mercato delle fee locale e controllato. Questo non solo rende i Prop AMM praticabili su EVM, ma potrebbe anche rivoluzionare tutta la DeFi EVM che dipende dagli aggiornamenti degli oracle in cima al blocco.

Questioni aperte

· La velocità dei Flashblock da 200ms su EVM è sufficiente per competere con l’architettura continua di Solana?

· Su Solana, la maggior parte del traffico AMM proviene da un singolo aggregatore, Jupiter, che offre un SDK per l’integrazione degli AMM. Su Layer 2 EVM, il traffico è distribuito tra più aggregatori e non esiste un SDK pubblico: questo rappresenta una sfida per i Prop AMM?

· Su Solana, l’aggiornamento di un Prop AMM consuma solo circa 100 CU: come viene implementato?

· Il modello di canale veloce garantisce solo l’aggiornamento in cima al blocco. Se ci sono più swap in un Flashblock, come può il market maker aggiornare il prezzo tra questi swap?

· È possibile scrivere programmi EVM ottimizzati in Yul o Huff, simili alle ottimizzazioni Pinocchio su Solana?

· Come si confrontano i Prop AMM con gli RFQ?

· Come si può evitare che un market maker offra una quotazione vantaggiosa nel blocco N per attirare utenti, per poi aggiornarla a una quotazione sfavorevole nel blocco N+1? Come fa Jupiter a prevenire ciò?

· La funzione Ultra Signaling di Jupiter Ultra V3 consente ai Prop AMM di distinguere tra traffico dannoso e innocuo e di offrire quotazioni più strette. Quanto sono importanti queste caratteristiche degli aggregatori per i Prop AMM su EVM?

Link originale