Nel 'foresta oscura' di Solana, quando ricevi un segnale di aggiornamento del conto dal modulo Scout, la competizione è già agli ultimi millisecondi. Se devi inviare nuovamente la transazione al nodo RPC per eseguire una 'simulazione' e ottenere un prezzo, quando ottieni il risultato, l'opportunità è spesso già stata presa dai concorrenti che hanno completato i calcoli localmente.

Un vero Searcher professionista non aspetta mai il feedback del nodo RPC. Mantiene una copia speculare dello stato AMM nella memoria locale e, al momento in cui riceve i dati binari, calcola direttamente il prezzo ottimale tramite modelli matematici.

Questo articolo analizzerà come costruire un motore di determinazione dei prezzi locale efficace per Raydium (CPMM) e Orca (CLMM).

1. Concetto chiave: calcolo locale vs. simulazione RPC

1.1 Perché scegliere la determinazione dei prezzi locali?

  • Latenza estrema: la simulazione RPC richiede solitamente 50ms-200ms, mentre il calcolo puramente matematico locale richiede solo microsecondi.

  • Capacità di concorrenza: il calcolo locale non consuma le performance dei nodi RPC, permettendo di eseguire istantaneamente la determinazione dei prezzi su migliaia di percorsi di arbitraggio.

  • Determinismo: analizzando i dati contabili originali (Dati dell'Account), puoi ottenere un controllo dello stato più profondo rispetto alla simulazione.

2. Raydium (CPMM): l'arte del prodotto costante

Il pool standard di Raydium segue la classica formula x×y=k. Anche se la logica è semplice, nella sua implementazione ingegneristica è necessario gestire piccole deviazioni di precisione e commissioni.

2.1 Formula di quotazione principale

In uno scenario con commissioni, la formula per calcolare la versione intera di amount_out è:

  1. Input con commissioni: AmountInwith_fee=AmountIn×(FeeDenominator−FeeNumerator)AmountInwith_fee​=AmountIn×(FeeDenominator−FeeNumerator)

  2. Calcolo dell'output: AmountOut=AmountInwith_fee×ReserveoutReservein×FeeDenominator+AmountInwith_feeAmountOut=Reservein​×FeeDenominator+AmountInwith_fee​AmountInwith_fee​×Reserveout​​

2.2 Gioco di precisione: necessità di U256

Su Solana, il numero di token è solitamente u64. Ma nel calcolare il numeratore della formula sopra (Numerator), moltiplicare due grandi u64 porterà immediatamente a un overflow.

  • Soluzione: introdurre U256 nel livello intermedio del calcolo. Anche se la libreria ufficiale di Rust non lo fornisce direttamente, utilizzando il macro uint o la libreria primitive-types, possiamo garantire calcoli assolutamente precisi anche in condizioni di alta volatilità (grandi input).

3. Orca Whirlpool (CLMM): analisi precisa della liquidità concentrata

Rispetto a CPMM, il modello di liquidità concentrata (CLMM) di Orca è molto più complesso. Non riguarda solo il prezzo, ma anche il Tick (intervallo di prezzo) e la profondità di liquidità.

3.1 Rappresentazione del prezzo: Q64.64 sqrtPrice

Orca utilizza il prezzo quadrato (sqrtPrice) e lo memorizza in formato floating point Q64.64.

  • Formula: Price=(sqrtPriceX64264)2Price=(264sqrtPriceX64​)2

  • Durante l'analisi, dobbiamo gestire interi enormi a 128 bit, estraendo il prezzo reale tramite operazioni di spostamento.

3.2 Analisi rapida: metodo di slicing Offset

La struttura dell'account di Orca è molto ampia (include più gruppi di premi, parametri delle commissioni, ecc.), se si utilizza la deserializzazione completa (Borsh Deserialize), il costo delle prestazioni è molto elevato.
Soluzione di ottimizzazione di livello industriale:
Localizzare direttamente i dati binari dell'account tramite Offset. Poiché la struttura del pool è fissa, possiamo leggere direttamente i byte chiave:

  • data[49..65] -> Liquidità (Liquidity)

  • data[65..81] -> Prezzo (sqrtPrice)

  • data[81..85] -> Tick attuale
    Questo metodo è più veloce di oltre 10 volte rispetto all'analisi completa.

4. Progettazione architettonica: livello di quotazione

Per consentire al livello strategico di non doversi preoccupare delle differenze matematiche tra i vari DEX, dobbiamo costruire un motore di quotazione unificato:

flowchart LR
RawData[Dati contabili originali] -->|Analisi| AMMState[Immagine di memoria AMM]
AMMState -->|Importo dell'input| LocalMath[Modello matematico locale]
LocalMath -->|Output| AmountOut[Quotazione strutturata]

subgraph "Livello di potenza computazionale locale"
LocalMath
AMMState
fine

Questo motore manterrà in tempo reale il saldo del vault del pool. Quando Scout rileva qualsiasi cambiamento in un Vault, il motore di quotazione ricalcolerà immediatamente il prezzo di tutto il percorso per quella coppia di token.

5. Ottimizzazione ingegneristica: velocità dai dettagli

  1. Calcolo della distribuzione zero: durante il calcolo, evitare il più possibile la distribuzione di memoria (Heap Allocation), utilizzando tipi nativi sulla pila.

  2. Elaborazione delle richieste RPC: anche se la determinazione dei prezzi è locale, il saldo del vault deve comunque essere sincronizzato. Utilizzare getMultipleAccounts per recuperare in batch tutti gli stati dei vault correlati, riducendo il round trip in rete.

  3. Precalcolo: per parametri fissi come le commissioni, completare l'analisi nella fase di avvio a freddo, senza ripetere il calcolo in ogni millisecondo del percorso caldo.

6. Dimostrazione tecnica: logica di quotazione CPMM (versione Python)

Anche se l'ambiente di produzione mira alle massime prestazioni di Rust, la sua logica matematica di base può essere chiaramente dimostrata in Python:

# Simulazione del calcolo locale ad alte prestazioni
def calculate_local_quote(amount_in, res_in, res_out, fee_pct=0.0025):
"""
Determinazione dei prezzi locali CPMM: x * y = k
"""
# Simulazione dei calcoli U256, per prevenire l'overflow
fee_numerator = int(fee_pct * 10000)
fee_denominator = 10000

# 1. Calcolare l'input effettivo al netto delle commissioni
amount_in_with_fee = amount_in * (fee_denominator - fee_numerator)

# 2. Calcolare l'output secondo la formula
numeratore = amount_in_with_fee * res_out
denominatore = (res_in * fee_denominator) + amount_in_with_fee

amount_out = numeratore // denominatore

# 3. Calcolo dell'impatto sul prezzo (Price Impact)
price_impact = (amount_out / res_out) se res_out > 0 altrimenti 1

return amount_out, price_impact

# Simulazione: 1 SOL scambia USDC, il pool contiene 1000 SOL / 100.000 USDC
out, impact = calculate_local_quote(1 10*9, 1000 10*9, 100000 10*6)
print(f"[*] Produzione stimata: {out / 10**6} USDC")
print(f"[*] Impatto sul prezzo: {impact:.4%}")

7. Riflessioni: potere computazionale è redditività

Nel mondo MEV di Solana, la capacità di determinazione dei prezzi locali determina il tuo livello competitivo.

  • I giocatori principianti si affidano alla simulazione RPC e possono solo bere la zuppa rimasta.

  • I giocatori intermedi implementano la localizzazione CPMM.

  • I giocatori avanzati possono analizzare con precisione ogni Tick del CLMM e implementare l'arbitraggio atomico con Jito.

Annuncio del prossimo passo

Ora che abbiamo "Scout" e "AMM Math", possiamo entrare nella parte più emozionante: come sviluppare strategie di arbitraggio cross-DEX? Di fronte a situazioni complesse con più percorsi e protocolli, come trovare il percorso più redditizio?

Questo articolo è stato scritto da Levi.eth. Su Solana, ogni ottimizzazione di una formula matematica può tradursi in reali guadagni on-chain.

JTO
JTOUSDT
0.3492
+3.43%
SOL
SOLUSDT
124.8
+1.09%