Vai al contenuto
Financial Context Wiki

Attacco inflazionistico al primo deposito ERC-4626: come l'arrotondamento può azzerare le quote

Scopri come una donazione diretta può manipolare il tasso di cambio di un vault ERC-4626 vuoto, arrotondare a zero le quote di un depositante e come implementazioni e utenti possono limitare il rischio.

Aggiornato

Solo a scopo educativo; non costituisce consulenza d’investimento. Investire può comportare perdite.

Risposta diretta

Un attacco inflazionistico al primo deposito prende di mira un vault ERC-4626 vuoto o quasi vuoto. L’attaccante deposita una quantità minima per ricevere le prime quote, quindi trasferisce direttamente al vault gli asset sottostanti. Questa donazione aumenta totalAssets() senza aumentare totalSupply(), rendendo più preziosa ogni quota esistente.

Se il deposito della vittima viene convertito al tasso manipolato, la divisione intera può arrotondare il risultato a pochissime quote o a zero. Gli asset della vittima restano nel vault, mentre l’attaccante, titolare delle quote in circolazione, può riscattare il diritto gonfiato. È un problema di manipolazione del tasso di cambio e slippage, non un difetto dell’interfaccia ERC-4626 stessa.

Come funziona

In un vault semplice senza commissioni o offset protettivi, le quote coniate per un deposito sono approssimativamente assets * totalSupply / totalAssets. ERC-4626 richiede che il calcolo delle quote per una data quantità di asset favorisca il vault arrotondando verso il basso. Ai normali tassi di cambio la perdita da arrotondamento è minima, ma quando il prezzo della quota è stato gonfiato, un deposito che vale meno di una quota può perdere il 100% per effetto dell’arrotondamento.

L’attacco dipende dai dettagli dell’implementazione. Un trasferimento diretto di ERC-20 può aumentare gli asset contabilizzati dal vault senza coniare quote, soprattutto quando totalAssets() legge il saldo di token del vault. L’attaccante deve inoltre precedere la vittima mentre l’offerta di quote è molto bassa. I vault che adottano una contabilità diversa o difese esplicite potrebbero non essere vulnerabili allo stesso modo.

Esempio

Supponiamo che un vault vuoto vulnerabile inizi con un rapporto di 1:1. L’attaccante deposita 1 unità di asset e riceve 1 quota, quindi dona direttamente 999 unità. Il vault contiene ora 1,000 asset a garanzia di 1 quota. La vittima deposita 999 unità, perciò il calcolo elementare dopo l’arrotondamento intero è 999 * 1 / 1,000 = 0 quote.

Il vault detiene quindi 1,999 asset, mentre esiste soltanto la 1 quota dell’attaccante. Se il deposito consente un risultato di zero quote e non vi sono commissioni o altri vincoli, l’attaccante può riscattare quella quota per tutti i 1,999 asset: la 1 unità depositata inizialmente, le 999 unità donate e le 999 unità depositate dalla vittima. Il profitto lordo dell’attaccante è pari alle 999 unità della vittima, prima dei costi di transazione.

Rischi e difese

Gli implementatori possono ridurre il rischio fornendo una liquidità iniziale significativa, bruciando o bloccando le quote iniziali, imponendo un risultato minimo di almeno una quota oppure usando un tasso di cambio con asset e quote virtuali. L’implementazione di OpenZeppelin aggiunge quantità virtuali e supporta una maggiore precisione delle quote tramite un offset dei decimali; nel modello documentato, le quote virtuali catturano parte di ogni donazione, rendendo la manipolazione non redditizia o molto più costosa. Ogni difesa ha presupposti propri e deve essere testata rispetto a trasferimenti diretti, soglie di arrotondamento, commissioni, perdite e comportamenti insoliti dei token.

Utenti e integratori devono considerare previewDeposit() una quotazione, non un minimo garantito. Invia i depositi tramite una funzione o un router che imponga un numero minimo accettabile di quote e annulli la transazione se il limite non viene raggiunto. Prima di depositare in un vault nuovo o con poche quote in circolazione, verifica totalAssets(), totalSupply(), la formula di conversione dell’implementazione e se trasferimenti di token non richiesti incidono sulla contabilità. Una quotazione favorevole del front-end non protegge una transazione il cui ordine di esecuzione può essere modificato.

Errori comuni

  • Mito 1: ERC-4626 garantisce da solo un tasso di cambio sicuro. Lo standard definisce un’interfaccia comune e il comportamento dell’arrotondamento, ma non rende ogni implementazione immune alla manipolazione del tasso di cambio.

  • Mito 2: chiamare previewDeposit() subito prima di deposit() garantisce quel risultato. Lo stato on-chain può cambiare tra le chiamate o prima dell’esecuzione. Il percorso di deposito richiede un limite minimo di quote applicabile.

  • Mito 3: rifiutare soltanto i depositi che generano zero quote elimina l’attacco. Evita l’esito più estremo, ma un attaccante può ancora far ricevere poche quote a un deposito e causare una grande perdita da arrotondamento. Le difese devono limitare lo slippage accettabile, non limitarsi a richiedere un risultato diverso da zero.

Argomenti correlati

Fonti

Navigazione

Cerca nella wiki...