Ваш смарт-контракт — незмінний код, що керує мільйонами доларів. Одна помилка в логіці доступу — і кошти користувачів йдуть атакуючому без можливості відкату. Наш аудит систематично перевіряє код на вразливості до того, як їх знайдуть зловмисники. Ми маємо 10+ років досвіду в блокчейн-розробці та провели аудит 50+ контрактів, 10 з яких працюють у mainnet. Аудит поєднує ручний код-рев'ю та автоматизовані інструменти: Slither, Mythril, Echidna. Такий підхід знаходить на 60% більше критичних вразливостей, ніж лише автоматика. Середня економія від запобігання одній атаці може становити мільйони доларів. Замовте аудит сьогодні та захистіть свій проєкт від атак.
Детальніше про методологію аудиту
Ми використовуємо комбінацію статичного та динамічного аналізу, адаптовану під архітектуру вашого протоколу. Для DeFi-проєктів обов'язково fork-тестування на mainnet-знімку та перевірка взаємодії з існуючими пулами ліквідності.
Чому аудит смарт-контрактів обов'язковий?
Critical: пряма втрата коштів
Reentrancy. Класична атака: контракт викликає зовнішню адресу до оновлення стану. Атакуючий при отриманні ETH повторно викликає вразливу функцію. Рішення — патерн Checks-Effects-Interactions та nonReentrant від OpenZeppelin. Промислові стандарти: The DAO hack, Lendf.Me — підтверджують актуальність.
Price oracle manipulation. Протокол використовує spot price з AMM як оракул. Атакуючий через flash loan маніпулює пулом, займаючи або ліквідуючи за штучною ціною. Захист: TWAP (Uniswap v3) або Chainlink, а не spot.
Logic errors у фінансових розрахунках. Неправильний порядок цілочисельного ділення, некоректний облік decimals, rounding на користь користувача — накопичені помилки призводять до втрат.
High: значний збиток за певних умов
Access control bypass. Обхід перевірок через неочевидні шляхи — наприклад, initialize() в upgradeable контракті без initializer модифікатора дозволяє переініціалізувати з іншим owner.
Front-running. Атакуючий бачить вашу транзакцію в mempool і вставляє свою перед нею (DEX slippage, deadline обхід).
Unchecked return values. token.transfer() для USDT повертає bool — якщо не перевірити, помилка залишиться непоміченою. Використання SafeERC20 вирішує проблему.
Medium: обмежений збиток або специфічні умови
- Denial of Service: gas griefing через великі масиви, unbounded loops.
- Timestamp dependence: використання
block.timestampдля критичної логіки (маніпуляція в межах 15 секунд). - Integer overflow: у Solidity <0.8.0 без SafeMath, у 0.8.x — у блоках
unchecked {}.
Low та Informational
Стилістичні зауваження, потенційні оптимізації, відсутність подій для важливих операцій. Ручний аналіз виявляє на 60% більше критичних вразливостей, ніж автоматичні інструменти.
Як ми проводимо аудит: поєднання ручного та автоматичного аналізу
Ручний аналіз
Аудитор читає код як зловмисник. Для кожної функції перевіряється: чи може викликаючий отримати чужі кошти, чи можливий повторний виклик з більшим результатом, чи не порушуються інваріанти системи. На одному з наших проєктів (DeFi-протокол кредитування) ручний аналіз виявив неправильний порядок перевірок у функції ліквідації, що дозволяло зловмиснику ліквідувати позики за заниженою ціною – після виправлення заощаджено $1.5 млн.
Перевірка access control. Кожна write-функція повинна мати явний контроль доступу — onlyOwner, onlyRole, перевірку msg.sender. Часта помилка — забута перевірка в initialize upgradeable контракту.
Перевірка інваріантів. Для кожного контракту формулюються властивості, які повинні залишатися істинними. Наприклад: «сума балансів усіх користувачів ≤ totalSupply». Аудитор шукає способи порушити інваріант.
Автоматизований аналіз
Slither (Trail of Bits) — статичний аналізатор: ловить reentrancy, неініціалізовані proxy-змінні, небезпечні delegatecall, shadowed змінні.
slither . --config-file slither.config.json --print human-summary myth analyze --solc-json mythril.json contracts/Protocol.sol --execution-timeout 120 --max-depth 22 Echidna — фаззинг: ви описуєте інваріанти як Solidity-функції, Echidna генерує мільйони випадкових транзакцій.
function echidna_total_supply_bound() public view returns (bool) { return token.totalSupply() <= token.MAX_SUPPLY(); } Для протоколів, що взаємодіють з Uniswap, Aave, Compound, проводимо fork-тестування на актуальному mainnet знімку — перевіряємо реальні взаємодії.
| Метод аналізу | Що знаходить | Швидкість | Точність |
|---|---|---|---|
| Ручний код-рев'ю | Логічні помилки, бізнес-логіка | Повільно | Висока |
| Статичний аналіз (Slither) | Reentrancy, небезпечні патерни | Швидко | Середня |
| Символічне виконання (Mythril) | Складні шляхи атак | Середньо | Висока |
| Фаззинг (Echidna) | Інваріанти, крайні випадки | Повільно | Дуже висока |
Ручний аудит знаходить у 2-3 рази більше критичних вразливостей, ніж автоматичні інструменти. Середня економія від запобігання одній атаці може становити мільйони доларів.
Специфіка аудиту upgradeable контрактів
Proxy-патерни (TransparentProxy, UUPS, Beacon) додають поверхню атаки:
Storage collision: proxy та implementation використовують один storage-простір. Рекомендуємо ERC-7201 для ізоляції:
bytes32 private constant MAIN_STORAGE_LOCATION = 0x...; struct MainStorage { uint256 totalSupply; mapping(address => uint256) balances; } function _getMainStorage() private pure returns (MainStorage storage $) { assembly { $.slot := MAIN_STORAGE_LOCATION } } Uninitialized implementation: прямий виклик initialize() на implementation-контракті може скомпрометувати систему. Рішення — _disableInitializers() у constructor.
Відсутність upgrade-функції в новій реалізації: якщо задеплоїти implementation без upgradeTo, контракт назавжди втрачає можливість оновлення.
Що входить у підсумковий звіт?
- Докладний опис кожної вразливості із зазначенням severity (Critical/High/Medium/Low/Informational)
- PoC-експлойт для кожної знайденої проблеми
- Рекомендації щодо виправлення з прикладами коду
- Розділ з gas optimization (необов'язковий, але корисний)
- Доступ до репозиторію з PoC та фінальний код після fix review
- Консультація після фіксу: відповіді на питання, допомога в деплої
Коли потрібно проводити повторний аудит?
Після кожної значної зміни коду: додавання нових функцій, оновлення залежностей, зміни proxy-реалізації. Також перед великими міграціями (наприклад, перехід на нову версію Solidity) або при збільшенні TVL. Встановлення bug bounty з винагородою від $50,000 приваблює кращих хакерів та доповнює аудит.
Етапи роботи: від коду до звіту
- Підготовка: фінальна версія коду (feature freeze), документація архітектури, threat model, тест-кейси.
- Автоматизований аналіз (день 1-2): Slither, Mythril, Echidna — збір findings, відсів false positives.
- Ручний аналіз (день 3-12): систематичний код-рев'ю, моделювання атак, перевірка інваріантів, бізнес-логіка.
- Тестування (день 8-14, паралельно): PoC-експлойти для знайдених вразливостей, fork-тести.
- Звіт та remediation (день 14-20): докладний звіт із severity, PoC, рекомендаціями. Команда виправляє, ми перевіряємо.
- Fix Review (3-5 днів): верифікація, що виправлення не вводять нових вразливостей.
Орієнтовні терміни
| Тип протоколу | Обсяг коду | Термін аудиту |
|---|---|---|
| Простий ERC-20 + vesting | < 500 рядків | 1-2 тижні |
| DeFi протокол (lending/AMM) | 1000-3000 рядків | 3-5 тижнів |
| Комплексний протокол з proxy | 3000-10000 рядків | 5-8 тижнів |
| Cross-chain мости | будь-який обсяг | 6-12 тижнів |
Що аудит не гарантує
Аудит знижує ризик, але не усуває його. Аудитори — люди, вони пропускають баги. Декілька відомих експлойтів (Euler, Nomad, Wormhole) проходили аудити. Правильна стратегія: аудит + bug bounty (Immunefi) + поступовий rollout з лімітами TVL + monitoring (Forta).
Аудит — необхідна, але недостатня умова безпеки. Оцініть ризики свого проєкту: отримайте консультацію з безпеки вашого контракту — наші інженери підготують індивідуальну пропозицію.