Cosa distingue gli smart contract dal resto del software?
Normalmente il software, anche quello che gestisce denaro, è un programma in esecuzione presso il computer di un qualche fiduciario. Ad esempio, il software del nostro internet banking funziona ed esegue dei compiti sulla base di istruzioni informatiche che gli sono state impartite e che noi non possiamo verificare in quanto utenti. Tali programmi sono poi attivabili e disattivabili a totale piacimento di chi li gestisce.
Trasparenza e verificabilità degli smart contract
Nel caso degli smart contract invece possiamo contare su un maggior livello di sicurezza, autonomia e trasparenza in quanto:
- Il codice dello smart contract è in genere visionabile e verificabile. Sappiamo esattamente quali istruzioni saranno eseguite e perché. Lo sappiamo anche se siamo dei semplici utenti grazie al fatto che il codice è validato in blockchain e come tale ispezionabile.
- Durante l’esecuzione, i dati che vengono forniti come input ad uno smart contract sono anch’essi verificabili dagli interessati in qualunque momento e non possono essere alterati durante il percorso dal loro computer alla rete blockchain.
- Allo stesso modo i risultati del calcolo di uno smart contract non sono solo visibili e verificabili sono anche inalterabili a posteriori garantendo che al verificarsi di una data condizione, il denaro da essi trattato, sarà sempre spedito al legittimo destinatario.
Queste caratteristiche sono vere a patto che lo smart contract sia effettivamente scritto in modo da non presentare backdoors, di non consentire upgrade o comunque di limitarli a precise regole prestabilite e che effettivamente sia scritto in modo sicuro e non presenti vulnerabilità
Il testing dimostra la presenza di bug non la loro assenza
E’ bene precisare che non esiste codice sicuro al 100% e nemmeno il code review o l’audit esterno può totalmente scongiurare la presenza di un malfunzionamento. Questo non significa che si possa lesinare sul testing e sui successivi code review interni ed esterni.
Impatto di un bug sugli smart contract
Non è un caso che quando uno smart contract che gestisce transazioni finanziarie sia affetto da un bug i problemi che ne derivano possono essere enormi e non recuperabili.
Resta emblematico il caso di TheDao hack nel 2016, che a causa di un reentrancy bug è stato sifonato da un utente malevolo e l’unico modo per poter recupare il maltolto è stato quello di attivare un hard fork a livello dell’intera rete Ethereum. Naturalmente si è trattato di un caso unico tale da richiedere una risposta così drastica. Ma nel caso del vostro smart contract nel 2022 non penso possiate contare che l’intera rete Ethereum decida per un hard fork.
Confronto dei danni tra smart contract e codice tradizionale
| Attacco/Bug | Software tradizionale | Smart contract |
|---|---|---|
| Denial of service | Il danno è proporzionale al tempo in cui persiste il denial-of-service. Minore è il tempo di recupero minore sarà il danno. | Tecnicamente non è possibile mandare il vostro contratto in DoS, ma l’intera rete Ethereum potrebbe rendere difficile l’interaione con il vostro contratto se le gas fee sono molto alte |
Data Leak | In questo caso se si tratta di dati personali o segreti industriali, gli hacker possono chiedere un riscatto e causare un danno economico e reputazionale. | Non avrebbe senso immaginare un data leak visto che gli smart contract eseguono codice e dati visibili ed eseguibili pubblicamente. Se tali dati sono offuscati prima di raggiungere la blockchain allora il bug non riguarderebbe lo smart contract |
| Data corruption | Nel software tradizionale ovviamente la corruzione dei data causa una perdita economica, ma è possibile in genere recuperare da backup e ripristinare lo stato corretto. L’impatto è dunque lineare e proporzionale al tempo di recovery | Data Corruption = LOSS. Questo è il caso più drammatico per lo smart contract. La corruzione di un dato o il valore inaspettato di un registro o variabile di stato può creare un disastro non recuperabile. |
Audit degli smart contract
L’audit del codice è una pratica giustamente ormai diffusa nell’industria sebbene abbia le sue limitazioni.
Infatti lo abbiamo detto e lo ribadiamo “nessun audit” può garantire che il vostro codice ad un dato momento non inizierà a manifestare gli effetti di un bug e come già detto prima “Il testing dimostra la presenza di bug non la loro assenza”.
Detto questo noi siamo molto favorevoli ad un approccio first test then code, non solo per ragioni legate alla sicurezza ma perché i testcase finiscono per diventare anche l’unica e più aggiornata fonte di documentazione sul codice stesso.
Gli audit non dovrebbero nemmeno essere chiamati audit ma più propriamente “code review esterni”, questo per garantire che chi effettua il code review non abbia interessi diretti nell’applicazione dello smart contract che sta analizzando. Quindi per una buona pratica prima di mettere in produzione uno smart contract con fondi “veri” dovremmo avere in piedi:
- test case esaustivi di ogni linea di codice inclusi i “corner case”
- code review interno da parte degli sviluppatori senior o consulenti del progetto
- code review esterno detto audit
Se hai un progetto e ti interessano i miei servizi di audit o consulenza sugli smart contract non esitare a contattarmi
Rispondi