Un audit è una fotografia, una suite di test è un'abitudine

L'audit di uno smart contract esamina una versione del codice, in un momento preciso, da persone che non l'hanno scritto. È un lavoro prezioso, ed è anche una fotografia. Non dice nulla sul commit successivo, e di commit il codice ne vedrà molti.

Cosa l'audit non copre

Dopo la consegna del report il codice continua a cambiare. Si aggiorna una dipendenza, si ritocca un parametro di commissione, si aggiunge una funzione per un cliente, si modifica all'ultimo minuto uno script di deploy. Nessuna di queste modifiche è descritta da un documento datato tre mesi prima. L'audit resta vero per la versione che ha esaminato, e diventa meno informativo sulla versione effettivamente distribuita a ogni modifica fatta da allora.

Tre tipi di test che portano avanti l'audit

Gli unit test controllano ogni funzione in isolamento e sono la base. I fork test eseguono i contratti su una copia dello stato reale della catena, così l'integrazione con protocolli già distribuiti si verifica e non si dà per scontata. Gli invariant test dichiarano proprietà che devono valere qualunque cosa accada: la somma dei saldi uguale alla fornitura totale, nessuno che prelevi più di quanto ha versato, un contratto in pausa che non accetta trasferimenti. Un fuzzer genera poi sequenze di chiamate che cercano di romperle, comprese sequenze a cui nessuno del team aveva pensato. Strumenti come Foundry e Hardhat supportano tutti e tre gli stili.

Test anche per ciò che non è logica del contratto

Molti incidenti in produzione nascono dal deploy e dall'upgrade, non dalla logica letta dall'audit. Mettete nella suite gli script di deploy, gli argomenti del costruttore e dell'inizializzatore, e il percorso di upgrade. Eseguite tutto nella integrazione continua a ogni modifica, in modo che un invariante che fallisce fermi un rilascio come farebbe un unit test in qualsiasi altro progetto .NET.

Come usare l'auditor

Chiedete all'auditor di consegnare ogni finding come riproduzione, e trasformatelo in un test che fallisce prima di correggerlo. Un finding diventato test non torna inosservato. Chiedete anche quali invarianti ha dato per assunti leggendo il codice, e scrivetele come test. Ne esce una suite che registra ciò che l'audit ha imparato, così il prossimo revisore parte da lì e non da zero. Per una software house che consegna a una PMI conta anche questo: la suite e gli script fanno parte della consegna, altrimenti il cliente eredita un audit e nessun modo di accorgersi che il codice è cambiato.

La regola è breve. L'audit è una tappa, la suite di test è il processo. Quale invariante del vostro contratto oggi non è scritta come test?