Зломи DeFi-протоколів — не виняток, а закономірність без належного аудиту смарт-контрактів. Ronin Bridge ($625M), Wormhole ($320M), Euler Finance ($197M) — це тільки вершина. Код цих проєктів переглядався розробниками, але свіжий погляд аудитора знайшов би проблеми на етапі розробки. За даними Chainalysis, сукупні втрати DeFi від зломів перевищили $3 млрд. Наш досвід у блокчейн-безпеці налічує понад 150 перевірених проєктів за 10+ років роботи. Якісний аудит смарт-контрактів — не опція, а необхідність для будь-якого серйозного протоколу.
Що включає повноцінний аудит смарт-контрактів
Аудит — це не просто запуск автоматичних аналізаторів. Механічні інструменти (Slither, Mythril, Echidna) знаходять до 30–40% уразливостей, решта вимагає ручного аналізу логіки. Ручний аналіз виявляє в ~2 рази більше критичних уразливостей порівняно з автоматичними інструментами. Ручний code review: порядковий аналіз кожної функції, перевірка бізнес-логіки на відповідність специфікації. Більшість критичних уразливостей — це не технічні патерни на кшталт reentrancy, а логічні помилки. Автоматичний аналіз: Slither (статичний аналіз), Mythril (symbolic execution), Echidna (fuzzing). Формує базу для ручного аналізу, знаходить low-hanging fruit. Тест-кейси для уразливостей: для кожної знайденої проблеми формується Proof of Concept — код, що відтворює експлойт. Gas optimization: паралельно з безпекою — аналіз неефективних патернів (storage vs memory, зайві SLOAD/SSTORE, надлишкові events).
Класифікація уразливостей
| Критичність | Приклади | Вимагає |
|---|---|---|
| Critical | Reentrancy, arbitrary call, integer overflow | Негайного виправлення до deploy |
| High | Access control bypass, price manipulation | Виправлення до mainnet |
| Medium | Centralization risk, front-running | Оцінки та часто виправлення |
| Low | Gas inefficiency, missing events | Рекомендації |
| Informational | Code style, documentation | За бажанням |
Які уразливості найчастіше зустрічаються?
Reentrancy: класика, але зустрічається досі. Зовнішній виклик до оновлення state дозволяє рекурсивно дренувати контракт. Патерн checks-effects-interactions + ReentrancyGuard.
Price oracle manipulation: флеш-кредити дозволяють маніпулювати спотовою ціною AMM. Використання TWAP (time-weighted average price) замість spot price — обов'язковий захист для будь-якого lending протоколу.
Access control: onlyOwner замість role-based access control, відсутність timelock на критичних функціях, неправильна перевірка msg.sender у proxy patterns.
Signature replay: підпис, призначений для одного контракту/мережі, використовується в іншому. EIP-712 domain separator + nonce — стандартний захист.
// Приклад вразливого коду — signature без nonce та domain function claimReward(bytes memory signature, uint256 amount) external { bytes32 hash = keccak256(abi.encodePacked(msg.sender, amount)); require(recoverSigner(hash, signature) == trustedSigner, "Invalid sig"); token.transfer(msg.sender, amount); // УРАЗЛИВІСТЬ: немає nonce, той самий підпис працює повторно // УРАЗЛИВІСТЬ: немає domain, підпис переноситься на інший контракт } // Виправлена версія з EIP-712 function claimReward(bytes memory signature, uint256 amount, uint256 nonce) external { require(!usedNonces[nonce], "Nonce used"); bytes32 structHash = keccak256(abi.encode( CLAIM_TYPEHASH, msg.sender, amount, nonce )); bytes32 digest = _hashTypedDataV4(structHash); // EIP-712 domain included require(ECDSA.recover(digest, signature) == trustedSigner, "Invalid sig"); usedNonces[nonce] = true; token.transfer(msg.sender, amount); } Детальніше про EIP-712 — це стандарт, що захищає від replay-атак.
Як проходить аудит смарт-контрактів?
Покроковий план аудиту смарт-контрактів
- Onboarding (1–2 дні): документація від команди (специфікація, архітектурні схеми, опис бізнес-логіки). Чим краща документація — тим ефективніший аудит.
- Manual review (5–10 днів): аудитори занурюються в код. Мінімум два незалежні рев'ювери на один контракт.
- Automated analysis (паралельно): Slither, Mythril, кастомні Echidna properties.
- Draft report (2–3 дні): формування попереднього звіту з усіма знахідками.
- Remediation review (3–5 днів): команда виправляє, аудитори верифікують виправлення. Критичні знахідки вимагають повторної перевірки.
- Final report (1 день): публічний звіт з описом усіх знахідок та статусами виправлень.
| Етап | Тривалість |
|---|---|
| Onboarding | 1–2 дні |
| Manual review | 5–10 днів |
| Automated analysis | Паралельно |
| Draft report | 2–3 дні |
| Remediation review | 3–5 днів |
| Final report | 1 день |
Приклад з практики: reentrancy у функції виведення коштів
В одному з проєктів ми знайшли reentrancy у функції виведення коштів: контракт викликав зовнішній контракт до зменшення балансу. Написали PoC за 2 години. Команда впровадила ReentrancyGuard, що запобігло потенційному збитку в $2M.
Скільки часу займає аудит?
Середній термін — від 1 до 4 тижнів. Фактори, що впливають на тривалість: обсяг коду (кількість рядків та функцій), складність бізнес-логіки (наявність стейкінгу, лендінгу, флеш-кредитів), якість документації та кількість залежностей. Наші аудити вже запобігли збитку на суму, співставну з мільйонами доларів. Пропонуємо комбінацію приватного аудиту та публічного конкурсу для максимального покриття.
Що входить в аудит під ключ
Ми надаємо повний комплекс послуг:
- Документацію та специфікацію контрактів;
- Доступ до репозиторію для спільної роботи;
- Навчання команди best practices безпеки;
- Підтримку після аудиту протягом 30 днів.
Оцінимо ваш проєкт безкоштовно та запропонуємо індивідуальні терміни. Захистіть свій протокол з гарантією безпеки від експертів із 10+ років досвіду. Замовте аудит сьогодні, щоб не повторити долю зламаних проєктів.