fluxswap

La maggior parte del software vive sul fatto che i bug si possono correggere. Un contratto on-chain ti toglie questo comfort: è immutabile e custodisce il denaro altrui. Questo capovolge il modo in cui scrivi il codice, perché non verifichi più che il percorso felice funzioni, verifichi che una regola che deve valere sempre non possa essere infranta.

fluxswap è costruito attorno a questa differenza. I pool di liquidità, un router, lo staking e un timelock sono funzionalità, ma il vero lavoro sta negli invarianti che devono valere dopo ogni possibile sequenza di operazioni, compresa quella che nessuno ha previsto.

Un'app ordinaria ha un bug, rilasci una correzione, si va avanti. Un contratto on-chain è immutabile e custodisce il denaro altrui, quindi un bug nella logica del pool di liquidità non è un difetto, è un vettore attraverso cui qualcuno drena fondi. Non c'è una release numero due in cui lo correggi.

Questa unica proprietà cambia tutto. Scrivi partendo dal presupposto che chiunque guardi il contratto stia cercando un modo per infrangere le sue regole, e che l'unica difesa sia dimostrare che non possono essere infrante.

I test singoli verificano input specifici che inventi tu stesso, quindi verificano solo ciò che hai già previsto. I test di invarianti in Foundry fanno qualcosa di più forte: bombardano a caso il contratto con migliaia di sequenze di operazioni e dopo ciascuna verificano che la regola valga ancora.

Le somme dei token tornano, il prodotto delle riserve non cala, nessuno ha prelevato più di quanto ha versato. La differenza è fondamentale, perché è il fuzzer, non tu, a inventare lo scenario che infrange il contratto, e lo fa migliaia di volte di fila.

Questa salvaguardia non protegge da un bug nel codice ma dall'abuso di privilegi. Senza timelock il proprietario potrebbe reimpostare in silenzio i parametri del protocollo poco prima di un attacco. Con esso, ogni cambiamento del genere è visibile e ritardato, il che gli toglie l'effetto sorpresa.

Il risultato è un protocollo la cui sicurezza poggia su una prova, non sulla convinzione di aver testato i casi più importanti. Gli invarianti reggono attraverso migliaia di sequenze casuali, i cambiamenti sensibili sono ritardati dal timelock, e le regole più pericolose, come il prodotto costante delle riserve, sono imposte direttamente nel codice del contratto.