# Report Analisi MEV e Attività Automatizzata su Base L2 Documentazione relativa alle metodologie di analisi on-chain e ai risultati ottenuti durante la ricerca sull'attività MEV nella rete Base. ## Metodologia di analisi ### Tentativo 1: Estrazione tramite Receipts (Bruteforce) L'approccio iniziale prevedeva il recupero di ogni blocco tramite `eth_getBlockByNumber` e la successiva richiesta dei receipt per ogni singola transazione (`eth_getTransactionReceipt`). - Analisi: L'obiettivo era la lettura sistematica degli eventi (logs) per la classificazione dei trasferimenti ERC-20. - Risultato: Metodo inefficiente a causa dell'elevato consumo di crediti RPC e dei tempi di risposta. Con un block time di 2 secondi, il processing di 1000 blocchi ha richiesto oltre 3 ore. L'assenza di un nodo archivio dedicato ha reso questo approccio impraticabile per analisi su larga scala. ### Tentativo 2: Analisi Statistica e Database Relazionale Siamo passati all'estrazione dei soli dati contenuti nei blocchi (`eth_getBlockByNumber`), popolando un database PostgreSQL. - Dati: Inserimento di circa 200k blocchi. - Efficienza: Il tempo di elaborazione per 1000 blocchi è sceso a circa 3 minuti. - Analisi SQL: Identificazione di pattern tramite query mirate (es. attori con alto volume di transazioni, bassa varietà di metodi chiamati e target limitati). ## Categorie di attori e bot identificati L'analisi dei dati e il `tenderly_traceTransaction` di transazioni anomale (rilevate tramite le query mirate) ha permesso di isolare diverse tipologie di attività automatizzata: - Liquidity Maintainers (Aerodrome): Bot che monitorano lo slot0 delle pool per riposizionare la liquidità in base ai parametri di mercato. - Incentive-Driven Micro-Swap Bots: Bot che eseguono swap ripetuti, spesso in perdita, finalizzati esclusivamente all'attivazione delle logiche di reward (Gauge/emissions) di protocolli come Aerodrome. - Protocol-Guaranteed MEV: Attività di liquidazione sistematica garantita dai parametri dei protocolli. - Oracle Probe Spam: Traffico infrastrutturale che esegue chiamate ripetute agli oracoli (spesso risultanti in revert) per testare latenza e liveness della rete. - Proxy-based Keepers: Automazioni per smart wallet e checkpoint di protocollo, inclusi i servizi di Gelato. ## Method Tagging e Strumenti di Supporto A causa dei limiti imposti dai costi di tracing completo, è stata adottata una strategia di tagging basata sulla firma del metodo (primi 10 caratteri dell'input_data). ### Workflow operativo 1. Analisi di un dataset di 200k blocchi (circa 4 giorni di attività su Base). 2. Ranking dei metodi per frequenza d'uso e numero di sender univoci. 3. Tracing manuale di transazioni campione tramite Tenderly per l'identificazione della logica del contratto. 4. Etichettatura dei metodi nel database per la classificazione automatica del traffico pregresso e futuro. ### GUI di Analisi (Streamlit) È stata realizzata un'interfaccia in Python per velocizzare il tagging manuale: - Visualizzazione dei metodi non classificati con maggior traffico. - Integrazione diretta con le API di Tenderly per il tracing dei sample. - Calcolo automatico della mole di attività MEV basata sul volume delle transazioni taggate. ## SQL di riferimento ```sql CREATE TABLE IF NOT EXISTS blocks ( block_number BIGINT PRIMARY KEY, block_hash TEXT NOT NULL, timestamp TIMESTAMP WITH TIME ZONE NOT NULL ); CREATE TABLE IF NOT EXISTS transactions ( tx_hash TEXT PRIMARY KEY, block_number BIGINT REFERENCES blocks(block_number), from_address TEXT NOT NULL, to_address TEXT, value NUMERIC, gas_limit BIGINT, gas_price BIGINT, max_fee_per_gas BIGINT, max_priority_fee_per_gas BIGINT, input_data TEXT, nonce BIGINT, transaction_index INTEGER, status INTEGER -- 1 for success, 0 for failure ); -- Metodi "taggati" CREATE TABLE IF NOT EXISTS method_tags ( method_id TEXT PRIMARY KEY, -- First 10 chars of input_data tag_name TEXT NOT NULL, description TEXT ); CREATE INDEX IF NOT EXISTS idx_transactions_block_number ON transactions(block_number); CREATE INDEX IF NOT EXISTS idx_transactions_from_address ON transactions(from_address); CREATE INDEX IF NOT EXISTS idx_transactions_to_address ON transactions(to_address); CREATE INDEX IF NOT EXISTS idx_transactions_method_id ON transactions (SUBSTRING(input_data, 1, 10)); -- Identificazione bot tramite euristica: molte chiamate, pochi metodi, pochi target WITH stats AS ( SELECT from_address, COUNT(*) AS tx_count, COUNT(DISTINCT to_address) AS targets, COUNT(DISTINCT SUBSTRING(input_data,1,10)) AS methods FROM transactions WHERE input_data <> '0x' AND value = 0 GROUP BY from_address ) SELECT * FROM stats WHERE tx_count > 100 AND methods <= 3 ORDER BY tx_count DESC; -- Metodi più utilizzati SELECT SUBSTRING(input_data, 1, 10) as method_id, COUNT(*) as usage_count FROM transactions WHERE input_data <> '0x' GROUP BY SUBSTRING(input_data, 1, 10) ORDER BY usage_count DESC; ``` --- ## Risultato Eseguito il tagging manuale dei principali metodi ordinati per numero di transazioni eseguite, con i primi metodi della classifica che hanno "taggato" oltre 700.000 transazioni, fino ad arrivare ai metodi presenti "solo" in ordini di 100.000 o meno transazioni ```mermaid pie title Transazioni Taggate "Untagged / Unknown" : 32.99 "Liquidity Incentive Farming" : 12.34 "MEV Bot: Arbitrage" : 9.56 "Liquidity Tick Maintenance" : 9.13 "MEV Bot: Liquidation" : 6.8 "Eth Transfer" : 6.44 "Account Abstraction" : 6.41 "Gelato Keepalive" : 3.35 "ERC20 Transfer" : 2.61 "ERC20 Approval" : 2.15 "MEV: Flash Loan" : 2.1 "Uniswap V4 Swap" : 1.9 "Altro (Junk/Multicall/V2/V3)" : 4.2 ``` --- ### Sviluppi attuali La ricerca potrebbe proseguire focalizzandosi sull'automazione del tagging tramite l'analisi dei parametri estratti dai trace o analizzando alcuni metodi in particolare cercando magari di riprodurli. Si potrebbe inoltre cercare di stimare la quantità di valore estratto dai farmer di incentivi a lungo termine o la quantita di gas utilizzata dai bot contro quella degli utenti.