---
title: "Come monitorare gli aggiornamenti dei contratti proxy"
description: "Monitora le modifiche a implementazione, beacon e controllo dei proxy aggiornabili, quindi verifica codice, compatibilità dello storage, inizializzazione, permessi e comportamenti critici."
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.
# Come monitorare gli aggiornamenti dei contratti proxy
> Solo a scopo educativo; non costituisce consulenza finanziaria. Gli investimenti possono comportare perdite.
## Risposta diretta
Monitora il percorso di controllo di un sistema aggiornabile oltre all'indirizzo del proxy. Un avviso deve identificare chi può autorizzare ed eseguire un aggiornamento, l'eventuale ritardo obbligatorio, la vecchia e la nuova implementazione e i calldata di inizializzazione. Dopo l'esecuzione, leggi in modo indipendente la configurazione on-chain e verifica i comportamenti critici.
L'indirizzo del proxy e i suoi saldi possono restare invariati mentre il codice delegato modifica permessi, commissioni, contabilità, funzioni di pausa o logica di prelievo. Un audit precedente non copre automaticamente una nuova implementazione o la relativa inizializzazione.
## Come funziona
Per prima cosa identifica il modello di proxy. ERC-1967 definisce slot di storage separati per `eip1967.proxy.implementation`, `eip1967.proxy.beacon` e lo slot facoltativo `eip1967.proxy.admin`. Le modifiche dirette all'implementazione dovrebbero emettere `Upgraded`; quelle all'indirizzo beacon, `BeaconUpgraded`; e quelle allo slot amministratore, `AdminChanged`. Per un proxy beacon chiama anche `implementation()` sul beacon, perché questo può cambiare implementazione mentre lo slot beacon del proxy resta invariato.
Non dedurre il modello completo di autorità dallo slot amministratore. Un proxy Transparent può essere controllato tramite un `ProxyAdmin`, mentre l'autorizzazione agli aggiornamenti UUPS è implementata nel contratto logico corrente tramite `_authorizeUpgrade`. Traccia proprietari, ruoli, soglie multisig, timelock, governor, percorsi di emergenza e capacità di modificare tali controlli.
Usa sia sottoscrizioni agli eventi sia letture periodiche dello stato. ERC-1967 raccomanda gli eventi, ma non obbliga ogni implementazione a emetterli. Registra chain, blocco, transazione, proxy, implementazione o beacon, hash del codice runtime, esecutore e stato di controllo pertinente da endpoint RPC indipendenti. Avvisa per operazioni pianificate, annullate ed eseguite e attendi la politica di conferma o finalità scelta dalla chain prima di considerare definitivo lo stato.
## Esempio
Un proxy di prestito è controllato da un multisig 3 su 5 tramite un timelock di 24 ore. Quando viene pianificato un aggiornamento, il monitor registra identificativo della proposta, destinazione, calldata, primo orario di esecuzione, implementazione corrente, implementazione proposta e stato di verifica del codice sorgente. I revisori confrontano codice e layout dello storage, esaminano la chiamata di inizializzazione e controllano modifiche a ruoli, chiamate esterne, commissioni, regole di pausa e percorsi di prelievo.
Dopo l'esecuzione, il monitor rilegge lo slot ERC-1967 pertinente, verifica il codice runtime distribuito e controlla le condizioni successive previste, come versione dell'implementazione, amministratori o titolari di ruoli, stato di pausa, contabilità degli asset e anteprima di prelievo in sola lettura. Un secondo avviso scatta se l'indirizzo o l'hash osservato differisce dalla proposta revisionata oppure se il polling periodico trova una modifica non segnalata da alcun evento.
## Rischi
- **Rischio di controllo:** Un multisig nominale può essere aggirato da un altro proprietario, ruolo, modulo, governor, chiave di emergenza o timelock modificabile. Segui ogni percorso fino ai firmatari finali e al ritardo.
- **Rischio di codice e storage:** Codice non verificato, layout incompatibili, inizializzazione non sicura o dipendenze cambiate possono corrompere lo stato o concedere autorità indesiderata. Verifica l'esatto artefatto distribuito, non solo un branch del repository o il nome di un audit.
- **Rischio di monitoraggio:** Un singolo RPC, un indicizzatore basato solo sugli eventi, un front-end o un block explorer possono essere in ritardo o errati. Riconcilia eventi, storage, bytecode, ricevute delle transazioni e stato del protocollo tra fonti indipendenti.
- **Rischio di risposta:** Un avviso senza responsabile e procedura collaudata può arrivare troppo tardi. Definisci chi revisiona, sospende le integrazioni, comunica o esce durante il ritardo, riconoscendo il rischio aggiuntivo di approvazioni affrettate e link di recupero non ufficiali.
Procedura minima:
1. Censisci ogni proxy, beacon, implementazione, amministratore, ruolo e punto di ingresso per gli aggiornamenti su ciascuna chain.
2. Salva una baseline valida di slot, hash del codice, stato di controllo e risultati critici in sola lettura.
3. Invia un avviso prima dell'esecuzione quando la pianificazione tramite governance o timelock lo consente, e di nuovo all'esecuzione o all'annullamento.
4. Confronta destinazione, calldata, implementazione, bytecode, layout dello storage e stato successivo eseguiti con la proposta revisionata.
5. Escala modifiche inattese, condizioni successive fallite, sorgente non verificato o ritardo abbreviato o aggirato; non considerare l'indirizzo proxy invariato una prova di sicurezza.
## Idee sbagliate comuni
- **Mito 1: "Monitorare `Upgraded` è sufficiente."** Le modifiche all'implementazione beacon e i proxy non standard possono richiedere il monitoraggio di un altro contratto o il polling dello stato; gli eventi vanno riconciliati con letture dirette.
- **Mito 2: "Lo slot amministratore rivela chi controlla ogni aggiornamento."** Lo slot è facoltativo e i modelli Transparent, UUPS, beacon, governance e personalizzati collocano l'autorità in contratti e funzioni diversi.
- **Mito 3: "Il sorgente verificato o un audit passato dimostrano che l'aggiornamento è sicuro."** Verifica bytecode distribuito, ipotesi su compilatore e costruttore, compatibilità dello storage, inizializzazione, configurazione e comportamento della versione esatta.
## Argomenti correlati
- [Rischio dei moduli multisig](/it/crypto/multisig-module-risk/)
- [Contratto proxy](/it/crypto/proxy-contract/)
- [Collisione dello storage del proxy](/it/crypto/proxy-storage-collision/)
- [Pausa di emergenza del protocollo](/it/crypto/protocol-emergency-pause/)
- [Contratto aggiornabile](/it/crypto/upgradeable-contract/)
## Fonti
- [ERC-1967: slot di storage dei proxy](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultato: 2026-08-21)
- [Proxy](https://docs.openzeppelin.com/contracts/5.x/api/proxy) - OpenZeppelin (consultato: 2026-08-21)
- [Scrivere contratti aggiornabili](https://docs.openzeppelin.com/upgrades-plugins/writing-upgradeable) - OpenZeppelin (consultato: 2026-08-21)
- [Controllo degli accessi](https://docs.openzeppelin.com/contracts/5.x/access-control) - OpenZeppelin (consultato: 2026-08-21)
Source: https://wiki.fcontext.com/it/crypto/proxy-upgrade-monitoring/index.mdx