Vai al contenuto
Financial Context Wiki

Proxy aggiornabile non inizializzato: rischio di presa di controllo dell'inizializzatore

I proxy aggiornabili inizializzano il proprio storage tramite una chiamata all'inizializzatore invece del costruttore dell'implementazione. Questo articolo spiega il front-running, il blocco dell'implementazione e i controlli di distribuzione.

Aggiornato

Solo a scopo educativo; non costituisce consulenza né raccomandazione d’investimento. Gli investimenti possono comportare perdite.

Risposta diretta

I contratti aggiornabili non utilizzano un costruttore per impostare lo stato dell’agente, ma si basano sull’inizializzatore. Questo articolo illustra gli agenti non inizializzati, il blocco dell’implementazione e i controlli di distribuzione.

Quando il nuovo indirizzo proxy viene distribuito ma la transazione di inizializzazione non è stata ancora confermata, chiunque può provare a chiamare prima l’inizializzatore pubblico e diventarne il proprietario.

Quando l’agente viene distribuito, il costruttore non eseguirà la logica di inizializzazione del contratto nell’archivio dell’agente. Pertanto, i sistemi aggiornabili utilizzano spesso un inizializzatore che può essere chiamato solo una volta per impostare il proprietario, i parametri del token e i moduli. Se la funzione non è adeguatamente protetta o se la distribuzione e l’inizializzazione sono suddivise in due transazioni, un utente malintenzionato potrebbe richiamarla per prima.

Come funziona

Il processo di sicurezza inserisce i dati di chiamata di distribuzione e inizializzazione nella stessa transazione atomica e disabilita l’inizializzazione durante l’implementazione della costruzione del contratto per impedire che l’implementazione stessa venga presa in consegna. Il reinizializzatore viene utilizzato per aggiungere un nuovo stato alla nuova versione e deve anche limitare la versione e le autorizzazioni di chiamata. Il solo controllo del proprietario dell’agente senza verificare lo stato di inizializzazione dell’implementazione potrebbe comunque comportare rischi.

Le operazioni on-chain sono divise in quattro livelli: il portafoglio è responsabile della visualizzazione e della firma, RPC è responsabile della lettura e della trasmissione, il codice del contratto determina il cambiamento di stato e il consenso del blocco determina se la transazione sarà definitivamente confermata. La visualizzazione del “successo” a qualsiasi livello non può sostituire la verifica ad altri livelli.

Esempio

Il progetto distribuisce prima l’agente e successivamente prevede di chiamare inizializzare(team). L’aggressore monitora il pool di memoria e prima chiama l’inizializzazione (attaccante) con una tariffa più elevata, diventa amministratore, quindi passa a un’implementazione dannosa e trasferisce i fondi. La transazione di inizializzazione del team esegue il rollback, ma a questo punto il controllo viene perso.

Gas, slittamento e tempo di blocco nel caso vengono utilizzati per dimostrare il metodo di calcolo. Prima dell’operazione effettiva, è necessario leggere il prezzo, la liquidità, le autorizzazioni e lo stato del contratto dell’attuale catena e dell’attuale blocco. L’importo registra contemporaneamente il numero di token, il valore in dollari e l’intero grezzo sulla catena.

Rischi

I rendimenti devono essere calcolati in base al valore di uscita reale:

Valore di uscita netto = valore di mercato dell’asset - shock dei prezzi - commissione di protocollo - tassa di trasferimento - Gas - sconto sul rischio di attesa

Stabilire tre scenari di stress di congestione della rete, eccezione Oracle e aggiornamento dell’amministratore. Supponiamo che Gas si espanda cinque volte, che la profondità della pool scenda del 50%, che la stablecoin sia scontata del 5% e che non sia possibile uscire per un giorno. Se il reddito di un mese non riesce a coprire l’attrito dovuto alla pressione, un reddito elevato non fornisce una compensazione sufficiente.

Il protocollo singolo, la catena singola, il ponte singolo e la valuta stabile unica fissano rispettivamente i limiti superiori. Qualsiasi posizione che richieda che amministratori, oracoli, bridge, frontend e un singolo RPC siano normali allo stesso tempo per uscire dovrebbe essere ulteriormente ristretta e le molteplici dipendenze correlate non devono essere confuse con dispersione.

Errori comuni

  • Mito 1: Il saldo del front-end è il fatto sulla catena. Il front-end potrebbe essere memorizzato nella cache, indicizzato in ritardo o connesso alla rete sbagliata e deve essere sottoposto a convalida incrociata con le letture del contratto.

  • Mito 2: Aumentare il Gas o lo Slippage può risolvere qualsiasi fallimento. Il gas influisce solo sullo smistamento e lo slittamento non fa altro che allentare il prezzo; Gli errori di autorizzazione, Nonce e condizione del contratto non verranno riparati automaticamente.

  • Mito 3: il successo dei test di piccola entità significa sicurezza permanente. Gli aggiornamenti dell’amministratore, i parametri dinamici e le modifiche alla liquidità cambieranno i risultati e dovrebbero essere rivisti prima di ogni espansione di posizione.

Argomenti correlati

Fonti autorevoli

Navigazione

Cerca nella wiki...