Атака нескінченного карбування
Definition pending verification.
Атака нескінченного карбування, яку часто називають 'збоєм карбування' (mint glitch) або 'вразливістю повторного входу' (reentrancy vulnerability) у контексті смарт-контрактів, — це тип експлойту, за якого зловмисник маніпулює логікою контракту для карбування довільно великої кількості токенів або активів. Це зазвичай відбувається в протоколах децентралізованих фінансів (DeFi), особливо тих, що включають механізми карбування токенів, кредитування або забезпечення. Основна вразливість часто полягає в тому, як контракт обробляє зовнішні виклики або оновлює свій внутрішній стан під час транзакції. Наприклад, контракт може дозволити користувачеві внести заставу, викарбувати новий токен на основі цієї застави, а потім вивести заставу — все в межах однієї транзакції. Якщо контракт карбує новий токен перед перевіркою депозиту застави або правильним оновленням свого внутрішнього стану, зловмисник може викликати функцію карбування кілька разів у межах одного контексту транзакції. Кожен виклик може карбувати більше токенів на основі тієї ж початкової (або недостатньо перевіреної) застави, що призводить до створення 'нескінченної' або значно завищеної кількості токенів з нічого. Це знецінює токен і може вичерпати резерви протоколу. Запобігання таким атакам вимагає ретельного дизайну смарт-контрактів, включаючи використання патерну 'перевірки-ефекти-взаємодії' (checks-effects-interactions), захисту від повторного входу (reentrancy guards), правильних оновлень стану перед зовнішніми викликами та ретельного аудиту.
graph LR
Center["Атака нескінченного карбування"]:::main
Pre_logic["logic"]:::pre --> Center
click Pre_logic "/terms/logic"
Rel_advanced_propulsion_systems["advanced-propulsion-systems"]:::related -.-> Center
click Rel_advanced_propulsion_systems "/terms/advanced-propulsion-systems"
Rel_consciousness_simulation_hardware["consciousness-simulation-hardware"]:::related -.-> Center
click Rel_consciousness_simulation_hardware "/terms/consciousness-simulation-hardware"
Rel_cognitive_enhancement["cognitive-enhancement"]:::related -.-> Center
click Rel_cognitive_enhancement "/terms/cognitive-enhancement"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧒 Простими словами
Уявіть собі чарівну машину для печива, яка повинна давати вам одне печиво за кожну золоту монету, яку ви в неї покладете. Якщо машина зламана, ви можете покласти одну монету, отримати печиво, а потім використати *це* печиво, щоб обдурити машину, змусивши її думати, що ви поклали ще одну монету, і отримати нескінченну кількість печива!
🤓 Expert Deep Dive
Атаки нескінченного карбування використовують недоліки в логіці переходу стану смарт-контрактів, часто пов'язані з повторним входом (reentrancy) або неправильною обробкою зовнішніх викликів. Поширений патерн включає функцію, яка: 1) Приймає вхідні дані користувача (наприклад, заставу). 2) Виконує зовнішній виклик (наприклад, до контракту токена ERC777, який запускає зворотний виклик). 3) Оновлює внутрішній стан (наприклад, карбує токени, оновлює баланси). Якщо зовнішній виклик запускає повторний виклик (reentrant call) назад до початкової функції до того, як стан буде оновлено (наприклад, застава повністю врахована або баланс скориговано), зловмисник може це використати. Наприклад, у кредитному протоколі користувач вносить заставу C, викликає mint(loan_amount), яка внутрішньо викликає зовнішній контракт токена. Функція зворотного виклику (fallback function) цього контракту токена повторно входить у функцію mint, дозволяючи зловмиснику карбувати знову, використовуючи ту саму заставу C до того, як перший виклик mint завершить оновлення свого стану. Патерн 'перевірки-ефекти-взаємодії' (Checks-Effects-Interactions) є критично важливим: перевіряйте умови (Checks), оновлюйте внутрішній стан (Effects), а потім взаємодійте із зовнішніми контрактами (Interactions). Захист від повторного входу (Reentrancy guards, м'ютекси) також може запобігти рекурсивним викликам у межах одного контексту транзакції. Вразливості також можуть виникати через можливості повторного входу ERC777 або помилкові реалізації ERC20.