Аудит смарт-контрактів

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1306 послуг
Аудит смарт-контрактів
Середній
~3-5 днів
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1306
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1217
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    919
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1146
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    609
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    884

Аудит смарт-контрактів

Аудит смарт-контрактів — це не формальна галочка перед mainnet. Це єдина реальна можливість знайти вразливості до того, як їх знайдуть атакувальники. Вразливості в контрактах не можуть бути виправлені непомітно: експлойт є публічним, втрати миттєві, шкода репутації постійна. Ronin Bridge ($625M), Wormhole ($320M), Euler Finance ($197M) — усі ці взломи сталися в кодових базах, які переглядали команди розробників. Свіжий погляд професійних аудиторів — це не розкіш.

Що включає повноцінний аудит

Аудит — це не просто запуск автоматичних аналізаторів. Механічні інструменти (Slither, Mythril, Echidna) знаходять 30–40% вразливостей; решта потребує ручного аналізу логіки.

Ручний аналіз коду: побудрядковий аналіз кожної функції, перевірка бізнес-логіки на відповідність специфікації. Більшість критичних вразливостей — це не технічні паттерни на кшталт reentrancy, а логічні помилки.

Автоматичний аналіз: Slither (статичний аналіз), Mythril (символічне виконання), Echidna (фаззинг). Формує основу для ручного аналізу, знаходить низько висячі плоди.

Тест-кейси для вразливостей: для кожної знайденої проблеми формується Proof of Concept — код, що відтворює експлойт.

Оптимізація газу: паралельно з безпекою — аналіз неефективних паттернів (storage vs memory, непотрібні SLOAD/SSTORE, надмірні eventi).

Класифікація вразливостей

Критичність Приклади Потребує
Critical Reentrancy, довільний виклик, переповнення цілих чисел Невідкладне виправлення перед запуском
High Обхід контролю доступу, маніпуляція ціною Виправлення перед mainnet
Medium Ризик централізації, front-running Оцінка та часто виправлення
Low Неефективність газу, відсутні события Рекомендації
Informational Стиль коду, документація За бажанням

Топ вразливостей 2023–2024

Reentrancy: класика, але все ще зустрічається. Зовнішній виклик перед оновленням стану дозволяє рекурсивно осушити контракт. Паттерн checks-effects-interactions + ReentrancyGuard.

Маніпуляція цінового оракула: флеш-кредити дозволяють маніпулювати спотовою ціною AMM. Використання TWAP (часово-зважена середня ціна) замість спотової ціни — обов'язковий захист для будь-якого протоколу кредитування.

Контроль доступу: onlyOwner замість role-based контролю доступу, відсутність timelock на критичних функціях, неправильна перевірка msg.sender у прокси-паттернах.

Повтор підпису: підпис, призначений для одного контракту/мережі, використовується в іншій. EIP-712 domain separator + nonce — стандартний захист.

// Приклад вразливого коду — підпис без 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 включено
    require(ECDSA.recover(digest, signature) == trustedSigner, "Invalid sig");
    
    usedNonces[nonce] = true;
    token.transfer(msg.sender, amount);
}

Процес аудиту

Фаза 1 — Адаптація (1–2 дні): документація від команди (специфікація, архітектурні схеми, опис бізнес-логіки). Чим краще документація — тим ефективнішим буде аудит.

Фаза 2 — Ручний аналіз (5–10 днів): аудитори занурюються в код. Мінімум два незалежні рецензенти на контракт.

Фаза 3 — Автоматичний аналіз (паралельно): Slither, Mythril, користувацькі властивості Echidna.

Фаза 4 — Чорновик звіту (2–3 дні): формування попереднього звіту з усіма результатами.

Фаза 5 — Аналіз виправлень (3–5 днів): команда виправляє, аудитори перевіряють виправлення. Критичні знахідки потребують повторної перевірки.

Фаза 6 — Фінальний звіт: публічний звіт з описом усіх знахідок та статусів виправлення.

Вартість та часові рамки

Вартість аудиту залежить від обсягу коду (рядки Solidity), складності логіки та репутації аудитора. Топ-рівневі аудитори (Trail of Bits, OpenZeppelin, Spearbit, Code4rena) — $30,000–200,000+ на проект. Середній рівень — $10,000–40,000. Часові рамки: 1–4 тижні.

Конкурентні аудити (Code4rena, Sherlock, Cantina) — альтернатива або доповнення: публічне змаганння, сотні аудиторів, але нерівномірне покриття та відсутність гарантії глибини аналізу критичних функцій.

Для більшості DeFi проектів оптимально: один повноцінний приватний аудит + публічне змаганння для широкого покриття.