Вивчення минулих експлойтів смарт-контрактів чудово підходить для того, щоб стати кращим розробником Solidity. Нещодавно я провів деякий час, розглядаючи багато експлойтів, які відбулися за останні кілька років. Розуміння першопричини злому – це чудовий спосіб навчитися думати по-іншому про написання коду. Це також дає вам кращу інтуїцію щодо того, які компоненти є найбільш критичними при розгляді нових баз коду. Я рекомендую всім, хто хоче покращити свою гру Solidity, переглянути минулі експлойти на @RektHQ або ознайомитися з документацією @phylaxsystems, де ми маємо розбивку зломів і те, як твердження могли їм запобігти. Вивчаючи ці минулі хаки, я зрозумів, що часто експлойти можливі через відсутність перевірок у коді або неправильні розрахунки, які призводять до того, що протоколи вводять стани, в яких вони не повинні перебувати. Як тільки експлойт відбувся, помилка часто здається очевидною. Ми повинні забезпечити, щоб протоколам було легше їх ідентифікувати. Багатьом протоколам було б корисно витратити час на визначення інваріантів і переконатися, що вони не можуть бути порушені. Написання тверджень - відмінний спосіб переконатися в тому, що ці інваріанти ніколи не можуть бути порушені. Останнім експлойтом, який я витратив на вивчення, був експлойт Abracadabra з березня 2025 року, де було втрачено ~$13 млн: Помилка: sendValueInCollateral() витягнув реальні токени, але забув оновити внутрішні облікові змінні Експлойт: orderValueInCollateral() продовжував повідомляти про однакове значення застави навіть після того, як токени були видалені Результат: зловмисник неодноразово брав борги під «фантомну заставу», доки кошти не були вичерпані Твердження, яке перевіряє простий інваріант, що «заявлена застава» збігається з «фактичною заставою», запобігло б злому.