Immutabile, finché non trovi un bug
Un contratto pubblicato non si corregge: si aggiunge un proxy e una chiave di upgrade. È quella chiave, non la logica certificata dall'audit, la cosa da proteggere.
L'immutabilità è la prima cosa che ti dicono di uno smart contract, ed è vera: una volta pubblicato, il suo bytecode non si cambia più. Viene venduta come una garanzia — nessuno può spostare i paletti dopo, né il team, né il fondatore, né chi comprerà l'azienda domani. Poi arriva il primo bug vero e la garanzia diventa una trappola. Non correggi ciò che non puoi modificare. La soluzione che si adotta subito dopo è nota e più che ragionevole, ma disfa esattamente la proprietà che si stava vendendo — e quasi nessuna presentazione lo dice ad alta voce.
Il proxy, e la chiave che introduce
La soluzione standard è il pattern proxy. Il contratto si divide in due. Un contratto proxy tiene lo stato e l'indirizzo con cui tutti interagiscono, e inoltra ogni chiamata — tramite delegatecall — a un contratto di logica separato, che contiene il codice. Quando devi correggere un bug pubblichi una nuova logica, la v2, e fai puntare lì il proxy. L'indirizzo di cui gli utenti si fidano non cambia mai; cambia il comportamento che ci sta dietro.
È elegante e funziona. Ma crea qualcosa che un attimo prima non esisteva: una chiave amministrativa che decide quale logica esegue il proxy. Chi controlla quella chiave può cambiare cosa fa il contratto, dopo che le persone hanno già iniziato a fidarsi. Il punto di fiducia si è spostato in silenzio. Prima era "il bytecode non può cambiare". Adesso è "chi tiene la chiave di upgrade non ne abuserà".
La chiave conta più della logica certificata
È la parte che si perde. Hai pagato un audit, e l'audit ha certificato il contratto di logica: i suoi calcoli, i controlli di accesso, la gestione dei casi limite. Ma l'indirizzo che può sostituire quella logica sta fuori dalla garanzia dell'audit. Un report pulito sulla v1 non dice niente su chi può inserire una v3 alle due di notte.
Se quella chiave di upgrade è un singolo wallet — una sola chiave privata su un solo portatile — allora "immutabile e trustless" è testo da brochure. Hai ricostruito un amministratore di database con permessi di scrittura in produzione, solo con qualche passaggio in più e una bolletta di gas. Un attaccante che ruba quella chiave non gli serve un bug di reentrancy: non attacca affatto la logica, la aggiorna e basta. Il modello di sicurezza deve includere la chiave, non solo il codice.
Per una software house .NET la domanda è di governance
Per chi lavora su commessa questo sposta la due diligence, non solo l'architettura. È la stessa domanda che ci si fa su qualsiasi sistema critico: chi ha i permessi di scrittura in produzione, e cosa lo ferma. La risposta non è "aggiornabile o no", ma chi può aggiornare e cosa c'è in mezzo.
Tre presidi fanno quasi tutto il lavoro. Un multisig, perché un upgrade richieda più firme indipendenti invece della chiave di una persona sola. Un timelock, perché una modifica in coda resti visibile sulla catena per un ritardo fisso prima di attivarsi — abbastanza da lasciare reagire chi guarda. E una spiegazione in chiaro del meccanismo, perché il cliente sappia di cosa si fida prima di metterci dei fondi. Un'immutabilità che non puoi correggere è un rischio. Un'aggiornabilità che nessuno vede arrivare è peggio. In una due diligence su un progetto blockchain, questa domanda pesa più dell'audit.
Sul vostro contratto, chi può cambiarne il comportamento domani — e con quanto preavviso?