Studiare gli exploit passati dei contratti smart è eccellente per diventare un miglior sviluppatore Solidity. Recentemente ho trascorso del tempo a rivedere molti degli exploit che si sono verificati negli ultimi due anni. Comprendere la causa principale di un hack è un ottimo modo per imparare a pensare in modo diverso quando si scrive codice. Dà anche una migliore intuizione su quali componenti siano più critici quando si esaminano nuove basi di codice. Raccomando a chiunque voglia migliorare il proprio gioco in Solidity di esaminare gli exploit passati su @RektHQ o di controllare la documentazione di @phylaxsystems, dove abbiamo analisi di hack e come le asserzioni avrebbero potuto prevenirli. Studiano questi hack passati, ho realizzato che spesso gli exploit sono possibili a causa di controlli mancanti nel codice o calcoli errati che portano i protocolli a entrare in stati in cui non dovrebbero trovarsi. Una volta che l'exploit è avvenuto, il bug sembra spesso ovvio. Dobbiamo assicurarci che i protocolli abbiano un modo più semplice per identificare questi problemi. Molti protocolli trarrebbero beneficio dal dedicare tempo a definire invarianti e assicurarsi che questi non possano essere violati. Scrivere asserzioni è un ottimo modo per garantire che queste invarianti non possano mai essere violate. L'ultimo exploit su cui ho trascorso del tempo a indagare è stato l'exploit di Abracadabra di marzo 2025, dove sono stati persi ~$13 milioni: Il Bug: sendValueInCollateral() ha estratto token reali ma ha dimenticato di aggiornare le variabili contabili interne. L'Exploit: orderValueInCollateral() continuava a segnalare lo stesso valore di collaterale anche dopo che i token erano stati rimossi. Risultato: l'attaccante ha preso in prestito contro "collaterale fantasma" ripetutamente fino a svuotare i fondi. Un'asserzione che controlla la semplice invariante che il "collaterale segnalato" corrisponde al "collaterale effettivo" avrebbe prevenuto l'hack.