Att studera tidigare bedrifter av smarta kontrakt är utmärkt för att bli en bättre Solidity-utvecklare. Jag har nyligen ägnat en del tid åt att granska många av de exploateringar som har inträffat under de senaste åren. Att förstå grundorsaken till ett hack är ett bra sätt att lära sig att tänka annorlunda när det gäller att skriva kod. Det ger dig också en bättre intuition för vilka komponenter som är mest kritiska när du tittar på nya kodbaser. Jag rekommenderar alla som vill förbättra sitt Solidity-spel att gå igenom tidigare bedrifter på @RektHQ eller kolla in @phylaxsystems dokument, där vi har uppdelningar av hacks och hur påståenden kunde ha förhindrat dem. Genom att studera dessa tidigare hack har jag insett att exploateringarna ofta är möjliga på grund av att de saknar kontroller i koden eller felaktiga beräkningar som leder till att protokoll går in i tillstånd som de inte är avsedda att vara i. När exploateringen väl har inträffat verkar buggen ofta uppenbar. Vi måste se till att det blir lättare att identifiera dessa i protokollen. Många protokoll skulle dra nytta av att ägna tid åt att definiera invarianter och se till att dessa inte kan överträdas. Att skriva påståenden är ett bra sätt att se till att dessa invarianter aldrig kan överträdas. Den senaste exploateringen jag ägnade tid åt att titta närmare på var Abracadabra-exploateringen från mars 2025 där ~13 miljoner dollar gick förlorade: Buggen: sendValueInCollateral() extraherade verkliga tokens men glömde att uppdatera interna redovisningsvariabler Exploateringen: orderValueInCollateral() fortsatte att rapportera samma säkerhetsvärde även efter att tokens togs bort Resultat: Angriparen lånade mot "fantomsäkerhet" upprepade gånger tills pengarna var tömda Ett påstående som kontrollerar den enkla invarianten att den "rapporterade säkerheten" matchar den "faktiska säkerheten" skulle ha förhindrat hackningen.