--- title: "Rischi dello storage con delegatecall" description: "Delegatecall esegue il codice di un altro contratto sullo storage del contratto chiamante. Scopri come collisioni dello storage, autorità di aggiornamento e destinazioni non attendibili possono compromettere un proxy o uno smart wallet." image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # Rischi dello storage con delegatecall > Solo a scopo educativo; non costituisce consulenza d'investimento. Investire può comportare perdite. ## Risposta diretta `delegatecall` esegue il codice di un contratto di destinazione nel contesto del contratto chiamante. Il chiamante mantiene il proprio storage, il proprio saldo e `address(this)`, mentre `msg.sender` e `msg.value` conservano i valori della chiamata originale. Questo comportamento rende possibili proxy, librerie e moduli di smart wallet, ma conferisce anche al codice delegato l'autorità effettiva del chiamante. Una scrittura nello storage, un trasferimento di asset, un'approvazione o una chiamata esterna vengono eseguiti come chiamante, non come destinazione che ha fornito il codice. Tratta ogni destinazione raggiungibile tramite `delegatecall` come codice privilegiato. La sicurezza dipende dalle regole di selezione della destinazione, dalla compatibilità dei layout dello storage, dallo stato di inizializzazione, dai controlli sugli aggiornamenti e dall'esatta implementazione attiva per la transazione. ## Come funziona Con una normale chiamata esterna, il contratto chiamato legge e scrive nel proprio storage. Con `delegatecall`, il bytecode della destinazione viene eseguito sullo storage del chiamante: un'istruzione `SSTORE` modifica uno slot appartenente al chiamante. I nomi delle variabili della destinazione non contano durante l'esecuzione; contano solo le posizioni calcolate degli slot. Questo crea quattro confini da sottoporre ad audit: - **Controllo della destinazione:** determina se la destinazione è fissa, selezionata da un utente, risolta tramite un registro o modificabile da un amministratore. - **Compatibilità dello storage:** confronta ordine e tipi delle variabili, ereditarietà, spazi riservati nello storage e slot con namespace o standardizzati in ogni versione dell'implementazione. - **Inizializzazione e autorizzazione:** verifica che gli inizializzatori non possano essere eseguiti nuovamente e che le funzioni di aggiornamento o gestione dei moduli impongano il chiamante previsto e il ritardo di governance stabilito. - **Gestione dei valori restituiti:** verifica che gli errori vengano propagati e che i dati restituiti siano decodificati come il tipo previsto; le chiamate di basso livello non forniscono i normali controlli di Solidity sul tipo di contratto. ERC-1967 riduce le collisioni nei proxy collocando gli indirizzi di implementazione, beacon e amministratore in slot standardizzati al di fuori della normale allocazione del compilatore. Non dimostra che un'implementazione sia sicura né che un aggiornamento autorizzato sia innocuo. ## Esempio Supponiamo che un wallet memorizzi `owner` in `slot 0`. Un plug-in compilato con `counter` in `slot 0` incrementa il contatore quando il wallet lo richiama tramite `delegatecall`. La scrittura modifica il valore `owner` del wallet perché lo storage appartiene al wallet. Se la parola risultante codifica un indirizzo controllato da un attaccante, i successivi controlli di autorizzazione potrebbero riconoscere l'attaccante come proprietario, anche se il plug-in non ha mai custodito gli asset del wallet. Una ricevuta con esito positivo non distingue le modifiche di stato intenzionali da quelle dannose. La simulazione della transazione deve quindi esaminare le differenze nello storage, le variazioni di asset e approvazioni, gli eventi emessi e le chiamate successive rispetto agli indirizzi esatti del proxy e dell'implementazione. ## Rischi - **Esecuzione su destinazioni arbitrarie:** destinazioni controllate dagli utenti o convalidate in modo insufficiente possono eseguire codice dannoso con le autorizzazioni del chiamante. - **Collisione dello storage:** un'implementazione può sovrascrivere proprietà, saldi, stato di pausa o persino lo slot che seleziona l'implementazione successiva. - **Aggiornamento non sicuro:** un amministratore o un processo di governance compromesso può sostituire codice precedentemente esaminato dopo che gli utenti hanno depositato asset o concesso approvazioni. - **Errore di inizializzazione:** un proxy o un'implementazione non inizializzati possono consentire a un altro account di rivendicare ruoli privilegiati o configurare dipendenze pericolose. - **Ispezione fuorviante:** verificare soltanto il codice sorgente del proxy, l'implementazione attuale o l'interfaccia può far trascurare un beacon, un aggiornamento in sospeso, un registro dei moduli o un percorso di esecuzione alternativo. Prima di firmare, individua l'implementazione a un blocco recente, verifica chi può modificarla e con quale ritardo, esamina il bytecode verificato e il layout dello storage della destinazione, simula tutti i calldata e confronta gli slot sensibili e le approvazioni dei token prima e dopo l'esecuzione. Per uno smart wallet, verifica anche come vengono abilitati e disabilitati i moduli e quali destinazioni possono scegliere. ## Errori comuni - **«La destinazione non può toccare gli asset del chiamante.»** Il codice delegato viene eseguito come chiamante e può invocare contratti esterni, trasferire asset o creare approvazioni se il chiamante dispone di tali capacità. - **«Nomi di variabili corrispondenti evitano le collisioni.»** L'EVM utilizza gli slot dello storage, non i nomi nel codice sorgente. L'ordine del layout, l'ereditarietà e i tipi devono rimanere compatibili. - **«Il codice verificato del proxy significa che il sistema è verificato.»** L'implementazione attiva, il beacon, l'amministratore degli aggiornamenti, lo stato di inizializzazione e le autorizzazioni dei moduli sono parti distinte del confine di fiducia. ## Argomenti correlati - [Sicurezza criptoeconomica](/it/crypto/crypto-economic-security/) - [RPC per transazioni private](/it/crypto/private-transaction-rpc/) - [Contratto proxy](/it/crypto/proxy-contract/) - [Smart contract](/it/crypto/smart-contract/) - [Simulazione delle transazioni](/it/crypto/transaction-simulation/) ## Fonti - [Introduction to Smart Contracts](https://docs.soliditylang.org/en/latest/introduction-to-smart-contracts.html) - Solidity Documentation (consultato: 2026-08-20) - [Units and Globally Available Variables](https://docs.soliditylang.org/en/latest/units-and-global-variables.html) - Solidity Documentation (consultato: 2026-08-20) - [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultato: 2026-08-20) Source: https://wiki.fcontext.com/it/crypto/delegatecall-storage-risk/index.mdx