💻 computer science

Slow and Steady: Preventing MEV with Verifiable Delays

Questo articolo propone un meccanismo di difesa contro il Maximal Extractable Value (MEV) nei registri distribuiti imponendo ritardi verificabili nella generazione delle transazioni, dimostrando la sua efficacia sia nei modelli bizantini che in quelli game-theoretic, delineando al contempo i suoi limiti teorici e la fattibilità pratica basata su dati storici.

Autori originali: Zeta Avarikioti, Dimitris Karakostas, Karl Kreder, Shreekara Shastry

Pubblicato 2026-08-14

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Zeta Avarikioti, Dimitris Karakostas, Karl Kreder, Shreekara Shastry

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un mondo in cui il denaro digitale non sia solo numeri in un conto bancario, ma un enorme registro pubblico che tutti possono vedere e aggiornare. Questo è il mondo della blockchain, la tecnologia alla base delle criptovalute come Bitcoin ed Ethereum. Pensatelo come a un enorme quaderno condiviso dove ogni transazione viene scritta in una nuova "pagina" di blocchi. Per mantenere questo quaderno onesto, un gruppo speciale di persone (o computer) chiamati "creatori di blocchi" si alterna nel scrivere queste nuove pagine. Sono i arbitri del gioco.

Tuttavia, in questa corsa digitale ad alta velocità, è emerso un problema subdolo chiamato MEV, o Maximal Extractable Value (Valore Massimo Estraibile). Immaginate una gara in cui la persona che corre sulla pista (il creatore del blocco) può sbirciare i piani dei corridori prima che inizino. Se vede un corridore sul punto di acquistare un oggetto raro, l'arbitro può intervenire, acquistarlo per primo e rivenderlo al corridore a un prezzo più alto, intascandosi la differenza. Nel mondo della blockchain, questo significa che la persona che scrive il blocco può riorganizzare le transazioni per ottenere un profitto rapido, spesso a spese degli utenti comuni. È come se l'arbitro truccasse il gioco per vincere una scommessa laterale. La grande domanda per scienziati e sviluppatori è: come possiamo impedire all'arbitro di truccare il gioco senza rallentare l'intera partita fino a renderla un passo d'oca?

Questo articolo, intitolato "Slow and Steady: Preventing MEV with Verifiable Delays" (Lento e costante: prevenire il MEV con ritardi verificabili), propone una soluzione intelligente ispirata alla vecchia favola della Tartaruga e della Lepre. Gli autori, Zeta Avarikioti e il suo team, suggeriscono che a volte, rallentare le cose è esattamente ciò di cui si ha bisogno per vincere. Introducono un meccanismo che impone un "ritardo verificabile" su ogni transazione. Pensatelo come a una clessidra magica che l'utente deve capovolgere prima che la sua transazione possa essere accettata. Questa clessidra impiega un tempo prestabilito per esaurirsi e, cosa fondamentale, nessuno può accelerarla, nemmeno se possiede un supercomputer.

Ecco come funziona la magia: quando un utente vuole inviare una transazione, non la urla semplicemente alla rete. Invece, prima la inserisce in una "scatola chiusa" (un impegno crittografico) e poi la fa passare attraverso un puzzle speciale chiamato Verifiable Delay Function (VDF - Funzione di Ritardo Verificabile). Questo puzzle è progettato in modo da richiedere un tempo specifico per essere risolto — diciamo 30 minuti — e non esiste modo per risolverlo più velocemente, indipendentamente da quanti computer vi si dedichino. Solo dopo che il puzzle è stato risolto, la transazione può essere rivelata e aggiunta alla blockchain.

L'articolo trova che questo ritardo crei uno scudo potente contro il MEV. Ecco la logica: se un creatore di blocchi vede una transazione che sembra un'opportunità di guadagno (come la possibilità di fare "sandwich" a un trade di un utente), normalmente cercherebbe di intervenire e riorganizzare l'ordine per rubare il profitto. Ma con questo nuovo sistema, nel momento in cui il creatore del blocco capisce l'opportunità e cerca di costruire un nuovo blocco per sfruttarla, la transazione originale è già stata bloccata e finalizzata a causa del ritardo obbligatorio. Il creatore del blocco è troppo lento per reagire. L'articolo dimostra matematicamente che se il ritardo è impostato su un tempo superiore a quello necessario affinché una transazione venga normalmente confermata, il "truccatore" semplicemente non può vincere.

Gli autori hanno anche esaminato il lato della "teoria dei giochi", chiedendosi se persone razionali avrebbero ancora tentato di truccare il gioco. Hanno scoperto che se tutti seguono le regole, nessuno ha l'incentivo di infrangerle perché il ritardo rende impossibile trarre profitto dal trucco. Tuttavia, hanno anche identificato uno scenario "negativo": se tutti decidessero di colludere e ignorare le regole insieme, potrebbero comunque causare problemi, ma questo è un problema generale di qualsiasi sistema, non solo di questo.

Fondamentalmente, l'articolo non offre solo teoria; verifica il mondo reale. Gli autori hanno analizzato dati storici di Ethereum e di altre reti. Hanno scoperto che, sebbene alcune opportunità di MEV siano enormi (milioni di dollari), la stragrande maggioranza — oltre il 99% — è in realtà piuttosto piccola, spesso di pochi dollari o anche meno di un dollaro. Ciò suggerisce che un ritardo di circa 30 minuti (che è circa il doppio del normale tempo di sicurezza per Ethereum) sarebbe sufficiente a fermare quasi tutte queste piccole, fastidiose truffe, specificamente quelle non prevedibili.

L'articolo conclude che questo approccio "Slow and Steady" è una difesa realistica. Suggerisce che possiamo rendere le blockchain più eque e user-friendly accettando un briciolo di lentezza. Tuttavia, gli autori avvertono con cautela che questo non è un bacchetta magica per tutto. Funziona molto bene per cose come la registrazione di un NFT o l'invio di denaro, dove aspettare 30 minuti è accettabile. Ma per il trading ad alta velocità su uno scambio decentralizzato, dove i prezzi cambiano in pochi secondi, questo ritardo potrebbe essere troppo lungo e potrebbe effettivamente danneggiare gli utenti che sta cercando di proteggere. L'articolo suggerisce che questo strumento debba essere usato con saggezza, forse solo per tipi specifici di applicazioni dove la velocità non è la cosa più importante.

In breve, l'articolo sostiene che imponendo un "tempo di attesa" che non può essere truccato, possiamo livellare il campo di gioco. Trasforma la corsa da uno sprint dove il più veloce (e talvolta il più subdolo) vince, in una marcia costante dove tutti arrivano contemporaneamente e l'arbitro non può truccare il traguardo.

Riepilogo Tecnico: Slow and Steady – Prevenire l'MEV con Ritardi Verificabili

Problematica

Il documento affronta la minaccia del Maximal Extractable Value (MEV) nei registri distribuiti. L'MEV si riferisce alla capacità dei creatori di blocchi (miner o validatori) di trarre profitto iniettando, riordinando o riorganizzando le transazioni all'interno di un blocco. Le strategie comuni di MEV includono il front-running, il back-running e gli attacchi "sandwich", in cui un attore malintenzionato sfrutta la transazione di un utente per generare profitto a spese dell'utente o dello sviluppatore dell'applicazione.

Gli autori identificano due impatti negativi primari dell'MEV:

Drenaggio di Asset: Il valore fluisce dagli utenti ai creatori di blocchi, degradando l'usabilità del sistema.
Rischi di Sicurezza: L'MEV crea incentivi off-chain che non sono controllati dal protocollo del registro. Se questi incentivi sono sufficientemente elevati, le parti guidate dal profitto potrebbero deviare dal protocollo per catturare l'MEV, potenzialmente compromettendo la sicurezza del consenso e la liveness.

Le contromisure esistenti, come le aste MEV (ad esempio, la Proposer-Builder Separation), si affidano a intermediari fidati. Le soluzioni di ordinamento basate sul tempo spesso faticano a garantire l'equità senza meccanismi complessi, e gli approcci agnostici rispetto al contenuto (schemi commit-reveal) ritardano il calcolo dello stato e oscurano il contenuto della transazione, impedendo ai creatori di blocchi di calcolare razionalmente i premi attesi.

Metodologia

Il documento propone un meccanismo di difesa che impone un Ritardo Verificabile sulla generazione delle transazioni. L'intuizione centrale è quella di rallentare la capacità di un creatore di blocchi di reagire a una nuova transazione osservata. Se il ritardo è sufficientemente lungo, una transazione onesta sarà finalizzata prima che un avversario possa costruire una transazione di front-running valida che dipenda da essa.

Il Meccanismo

Gli autori propongono una trasformazione del predicato di validità di una transazione di un registro distribuito utilizzando tre componenti:

Funzione di Ritardo Verificabile (VDF): Una primitiva crittografica che richiede un numero specifico di passi sequenziali ( $\tau$ ) per essere valutata, la quale non può essere significativamente accelerata tramite elaborazione parallela.
Schema di Impegno (Commitment Scheme): Un impegno crittografico al payload della transazione.
Trasformazione di Validità: Un nuovo predicato di validità, $\text{Validate}_{V^DF, CS}$ $Validate_{V^{D} F, C S}$ , è definito. Una transazione $tx = \langle m, (y, \pi) \rangle$ $t x = ⟨ m, (y, π)⟩$ è valida solo se:
- Il payload sottostante $m$ soddisfa le regole di validità del registro originale.
- L'output della VDF $y$ e la prova $\pi$ sono verificati correttamente.
- Il payload rivelato corrisponde all'impegno utilizzato per la valutazione della VDF.

Fondamentalmente, la VDF viene valutata sul commitment del payload della transazione, non sul payload stesso. Ciò consente agli utenti di esternalizzare il calcolo a terze parti senza rivelare il contenuto della transazione, impedendo al fornitore del servizio di lanciare un attacco MEV parallelo.

Modelli Teorici

L'analisi è condotta sotto due modelli:

Modello Byzantine: Assume un avversario adattivo e "rushing" che controlla un sottoinsieme di parti. L'obiettivo è dimostrare la Causalità dell'Input della Blockchain: un avversario non può creare una transazione valida che dipenda significativamente da una transazione onesta prima che tale transazione sia finalizzata.
Modello Teoria dei Giochi: Assume parti razionali che massimizzano l'utilità (premi del blocco, commissioni e MEV). L'analisi utilizza l'equilibrio $\epsilon$ -Nash e la compliance (dove le parti non deviano per compiere specifiche infrazioni come la censura).

Contributi Chiave e Risultati

1. Causalità dell'Input della Blockchain (Teorema 1)

Il documento dimostra che se il parametro di ritardo della VDF $\tau$ è maggiore del parametro di liveness del registro $u$ (il tempo necessario affinché una transazione onesta venga finalizzata), il protocollo trasformato garantisce la causalità dell'input.

Logica: Una transazione onesta trasmessa al round $r$ è finalizzata entro il round $r+u$ . Un avversario che tenta di effettuare il front-running di questa transazione deve prima osservarla, calcolare la VDF (che richiede $\tau$ round) e poi pubblicarla. Poiché $\tau > u$ , la transazione dell'avversario non può essere valida prima che la transazione onesta sia già stata finalizzata.
Risultato: La trasformazione preserva le garanzie di sicurezza e liveness del protocollo originale eliminando la capacità di front-running.

2. Preservazione dell'Equilibrio (Teorema 2)

Gli autori dimostrano che se il protocollo originale $\Pi$ è un $\epsilon$ -equilibrio di Nash in assenza di MEV ( $E_{-MEV}$ ), il protocollo trasformato $\tilde{\Pi}$ rimane un $\epsilon'$ -equilibrio di Nash anche quando esistono opportunità di MEV ( $E_{+MEV}$ ).

Significato: Questo fornisce un metodo costruttivo per i progettisti di protocolli per proteggere i registri razionali contro l'MEV senza rompere le proprietà di equilibrio del sistema sottostante.

3. Compliance contro la Censura (Teorema 4)

Il documento mostra che se il protocollo originale è conforme riguardo alla censura (le parti non censurano le transazioni per guadagnare utilità), il protocollo trasformato è conforme riguardo alla causalità dell'input della blockchain in un mondo con MEV.

Logica: Per reclamare l'MEV, una parte deve censurare una transazione per $\tau$ round. Poiché $\tau > u$ , la censura per questa durata viola la garanzia di liveness del protocollo sottostante. Poiché l'avversario non può unilateralmente rompere la liveness, non può censurare con successo abbastanza a lungo da reclamare l'MEV, rendendo la deviazione non redditizia.

4. Risultato Negativo (Teorema 3)

Il documento identifica anche un "equilibrio negativo" in cui tutte le parti colludono per censurare una transazione per $\tau$ round per reclamare il suo MEV. In questo scenario specifico, nessuna singola parte ha l'incentivo a deviare e pubblicare la transazione, poiché verrebbe censurata dal resto della rete. Ciò evidenzia un limite: il meccanismo previene il front-running individuale, ma non può prevenire attacchi di censura collettiva se il consenso della rete si sposta per sfruttare l'MEV.

Analisi Implementativa e Pratica

Candidati VDF

Gli autori valutano due candidati VDF primari:

VDF di Wesolowski: Mostra un'alta efficienza per il caso d'uso proposto. Il tempo di verifica rimane basso (~700ms) anche per tempi di calcolo che vanno da 15 a 60 minuti. Le dimensioni delle prove sono gestibili (<516 byte).
VDF di Pietrzak: Il tempo di verifica è logaritmico rispetto al tempo di calcolo, rendendolo meno adatto per questa specifica applicazione dove è richiesta una verifica veloce da parte di tutti i nodi.

Dati Storici MEV

L'analisi dei dati storici dai protocolli Layer-2 (Polygon, Arbitrum, Optimism) e dai dataset di Flashbots rivela che:

Sebbene i profitti massimi di MEV possano raggiungere milioni di dollari, la vasta maggioranza delle opportunità è piccola (spesso < $100, e frequentemente < $1).
Reclamare queste opportunità richiede spesso transazioni complesse e multi-step (ad esempio, 4-6 trasferimenti per l'arbitraggio).
Conclusione: Un ritardo di 15–30 minuti (fattibile con le attuali VDF) neutralizzerebbe efficacementamente la stragrande maggioranza delle minacce MEV esistenti, specificamente quelle non prevedibili, poiché il costo e la complessità del ritardo superano i piccoli profitti della maggior parte delle opportunità.

Considerazioni sull'Usabilità

Il documento riconosce che l'introduzione di ritardi impatta l'usabilità.

Applicazioni Idonee: Scenari che non richiedono una risposta immediata del mercato, come il minting di NFT o la registrazione.
Applicazioni Non Idonee: Il meccanismo non è adatto per difendere contro gli attacchi MEV che si basano esclusivamente sul back-running, poiché il suo focus è sugli attacchi di front-running. Inoltre, potrebbe non essere adatto per gli exchange decentralizzati (DEX) e le applicazioni sensibili ai movimenti di prezzo dove gli utenti devono rispondere rapidamente alle condizioni di mercato.
Flessibilità di Implementazione: Il meccanismo può essere implementato a livello di smart contract piuttosto che a livello di protocollo del registro, consentendo di applicarlo selettivamente a specifiche applicazioni DeFi.

Significato e Rivendicazioni

Il documento sostiene di offrire un meccanismo di difesa trustless contro l'MEV che si affida esclusivamente alla sicurezza del registro e alle primitive crittografiche, evitando la necessità di terze parti fidate o protocolli di ordinamento complessi.

Contributo Teorico: Stabilisce un legame formale tra i ritardi VDF e la prevenzione delle violazioni della causalità dell'input, dimostrando che le proprietà di sicurezza standard (safety, liveness, equilibrio) possono essere preservate o migliorate in presenza di MEV.
Contributo Pratico: Analizzando i dati storici, gli autori sostengono che il meccanismo è realisticamente implementabile e sufficiente a prevenire la maggior parte dei casi di MEV non prevedibili, poiché l'approccio "slow and steady" filtra efficacemente gli attacchi ad alta frequenza e basso valore.
Limitazioni: Gli autori notano con modestia che il meccanismo si basa su stime di sicurezza pratiche delle VDF (poiché mancano ancora rigorosi limiti inferiori teorici per l'efficace valutazione) e che non è una panacea per tutte le applicazioni DeFi, in particolare per quelle che richiedono trading ad alta frequenza o che sono vulnerabili esclusivamente al back-running.

In sintesi, il lavoro propone che, rallentando intenzionalmente la finalizzazione delle transazioni tramite ritardi verificabili, i registri distribuiti possono diventare più robusti contro gli attacchi di estrazione di valore, scambiando un grado di immediatezza con una maggiore sicurezza ed equità.