Å studere tidligere smarte kontraktsutnyttelser er utmerket for å bli en bedre Solidity-utvikler. Jeg har brukt litt tid på å gjennomgå mange av bedriftene som har skjedd de siste par årene. Å forstå årsaken til et hack er en fin måte å lære å tenke annerledes om å skrive kode. Det gir deg også en bedre intuisjon for hvilke komponenter som er mest kritiske når du ser på nye kodebaser. Jeg anbefaler alle som ønsker å forbedre Solidity-spillet sitt å gå gjennom tidligere utnyttelser på @RektHQ eller sjekke ut de @phylaxsystems dokumentene, hvor vi har sammenbrudd av hacks og hvordan påstander kunne ha forhindret dem. Ved å studere disse tidligere hackene har jeg innsett at utnyttelsene ofte er mulige på grunn av manglende kontroller i koden eller feil beregninger som fører til at protokoller går inn i tilstander de ikke er ment å være i. Når utnyttelsen har skjedd, virker feilen ofte åpenbar. Vi må sørge for at protokoller har lettere for å identifisere disse. Mange protokoller ville ha nytte av å bruke tid på å definere invarianter og sikre at disse ikke kan brytes. Å skrive påstander er en fin måte å sikre at disse invariantene aldri kan krenkes. Den siste utnyttelsen jeg brukte tid på å se på var Abracadabra-utnyttelsen fra mars 2025 hvor ~13 millioner dollar gikk tapt: Feilen: sendValueInCollateral() hentet ut ekte tokens, men glemte å oppdatere interne regnskapsvariabler Exploit: orderValueInCollateral() fortsatte å rapportere samme sikkerhetsverdi selv etter at tokens ble fjernet Resultat: Angriperen lånte mot «fantomsikkerhet» gjentatte ganger til midlene var tappet En påstand som sjekker den enkle invarianten at den «rapporterte sikkerheten» samsvarer med den «faktiske sikkerheten» ville ha forhindret hackingen.