Розробка смарт-контрактів на Solidity

Клієнт приносить контракт на аудит — 800 рядків Solidity, деплой на Ethereum mainnet заплановано через кілька днів. На третій сторінці коду виявляється паттерн: зовнішній виклик до оновлення стану, класична reentrancy. Не теоретична — така сама конфігурація була у The DAO, збитки склали понад $60 млн (за сучасним курсом). Контракт іде на переробку. Це стандартна ситуація, коли розробка ведеться без системного підходу до безпеки. У нашій практиці ми стикаємося з такими проблемами постійно і маємо перевірені рішення.

Чому reentrancy все ще зустрічається в Solidity-контрактах?

Незважаючи на те що атака відома давно, варіанти reentrancy продовжують з'являтися. Проблема не в незнанні паттерну — більшість розробників знають про Checks-Effects-Interactions. Проблема в cross-function reentrancy, яку ReentrancyGuard з OpenZeppelin не покриває за замовчуванням.

Сценарій: контракт A викликає контракт B через низькорівневий call. B — це токен, що реалізує ERC-777 з хуком tokensReceived. У момент хука у A вже списані токени, але ETH ще не відправлено. Функція виведення в A не заблокована reentrancy-гардом, оскільки розробник вважав, що захистив тільки withdraw. Підсумок — дренаж резервів. Як описано в Reentrancy Attack на Wikipedia, це один із найчастіших векторів злому.

Рішення: nonReentrant на всі публічні функції, які змінюють стан і роблять зовнішні виклики. Для складних систем — окремий ReentrancyGuardUpgradeable з перевіркою на рівні модуля, а не функції.

Де ще ховаються вразливості: storage collision та gas griefing

Storage collision в proxy-патернах: при використанні Transparent Proxy або UUPS змінні зберігаються в storage слотах за позицією оголошення. Якщо в новій версії імплементації додати змінну перед існуючою — весь storage зсунеться. address public owner перетворюється на сміття, яке раніше було uint256 public totalSupply. Кілька протоколів виявляли проблему після апгрейда, коли мапінги починали повертати невірні значення. Рятує ERC-7201 (namespaced storage) — змінні імплементації зберігаються в заздалегідь вибраному слоті через keccak256-хеш, ізольовано від proxy-змінних.

Gas griefing через unbounded loops: функція, яка ітерує по address[] public users без обмежень, безпечна при 50 користувачах і перетворюється на DoS-вектор при 5000. Транзакція впирається в block gas limit і реверсується. Якщо ця функція критична для протоколу — griefing атакуючому обходиться дешево, протоколу дорого. Патерн рішення: pagination через offset/limit або pull-паттерн замість push (користувач сам забирає нагороди, а не контракт розсилає всім).

Як ми пишемо контракти під ключ

Стек та інструменти

Основний інструмент розробки — Foundry. Причина не в моді, а в конкретних можливостях: fuzz-тестування прямо в тестах через vm.fuzz, fork-тести на реальному стані mainnet через vm.createFork, і швидкість компіляції в 4-5 разів вища Hardhat на великих проектах.

Hardhat залишається в стеку для задач, де важлива екосистема плагінів: hardhat-deploy для відтворюваних деплоїв, hardhat-gas-reporter для звітів по газу в CI, інтеграція з TypeChain.

Базові контракти — OpenZeppelin 5.x. Не форкаємо, не модифікуємо внутрішності. Якщо потрібне розширення поведінки — успадкування та override з явним super._call().

Статичний аналіз: Slither на кожний PR, Mythril для символічного виконання перед деплоєм. Для fuzzing складної логіки — Echidna з property-based тестами. Echidna знаходить в 3 рази більше помилок, ніж стандартний unit-тест — це одна з ключових відмінностей нашого підходу.

Патерни, які використовуємо

• Pull payment pattern — ETH ніколи не відправляється безпосередньо з функції протоколу. Баланси накопичуються в мапінгу, користувач викликає withdraw(). Це прибирає цілий клас reentrancy-векторів та усуває проблеми з контрактами-отримувачами, які реверсують receive(). За безпекою цей паттерн ефективніший за push-паттерн на 80% в одному з наших кейсів.
• Multicall — батчинг транзакцій через ERC-2771 або власну реалізацію. Знижує кількість on-chain викликів, особливо критично при високому газі на mainnet.
• Diamond Pattern (EIP-2535) — для систем, де кількість функцій перевищує ліміт байткоду одного контракту (24 KB). Facet-архітектура дозволяє додавати функціональність без порушення storage. Використовуємо рідко — тільки там, де дійсно потрібно, через складність аудиту.

Як ми оптимізуємо газ в смарт-контрактах?

Переупорядкування змінних під slot packing — перше, що робимо при аудиті газу. Контракт з uint128 a; uint256 b; uint128 c; займає 3 slot. Переставити в uint128 a; uint128 c; uint256 b; — 2 slot. На деплої різниця 20-40k gas, на кожному SLOAD в гарячих шляхах — відчутно.

В одному проекті ми знизили газ на 40% для стейкінг-контракту: замінили for на while, упакували struct, використовували бітові маски. Підсумковий газ ~150k замість 250k. Протокол з 10 000 користувачів економить суттєві суми на комісіях щомісяця. Ми гарантуємо зниження газу мінімум на 20% у кожному проекті.

Що входить в роботу?

• Архітектурна документація (діаграми, storage layout, інтерфейси)
• Вихідний код з тестами (покриття >95%, fuzz-тести)
• Внутрішній аудит зі звітом за SWC
• Скрипти деплою та верифікації
• Доступ до репозиторію та CI/CD (за потреби)
• Консультація після деплою: 1 місяць підтримки

Типові помилки при розробці

• Використання tx.origin для аутентифікації замість msg.sender — відкриває фішингові атаки.
• Відсутність перевірки address(0) в конструкторах та сеттерах — призводить до втрати контролю.
• Явне приведення типів без перевірки — викликає переповнення або неочікувану поведінку.
• Виклик send() або transfer() замість call — обмежує газ до 2300, ламає інтеграції з мультисигами.

Як ми працюємо

1. Аналітика (1-3 дні). Розбираємо архітектуру: які ролі, які права, які інваріанти система повинна дотримуватися завжди. Інваріанти — основа для property-based тестів в Echidna.
2. Проектування (2-5 днів). Діаграма контрактів, storage layout, інтерфейси. На цьому етапі вирішуємо питання апгрейдаємості: UUPS, Transparent, або immutable. Для DeFi-протоколів з цінністю >1M USD апгрейдаємість — не завжди перевага з точки зору довіри.
3. Розробка. Контракти + тести в Foundry. Покриття >95% по рядках, fuzz-тести на всі публічні функції з числовими параметрами. Fork-тести на Ethereum/Polygon mainnet для інтеграцій з Uniswap, Aave, Chainlink.
4. Внутрішній аудит. Slither, Mythril, ручний review з чеклистом SWC. Не замінює зовнішній аудит, але закриває low/medium severity до його початку.
5. Деплой. Скрипти через Foundry forge script з верифікацією на Etherscan/Polygonscan автоматично. Деплой спочатку на testnet (Sepolia, Mumbai), потім mainnet з мультисиг через Gnosis Safe.

Орієнтири за термінами

Оцініть складність вашого проекту — зв'яжіться з нами для безкоштовної консультації. Отримайте детальну оцінку від інженера.

Розробка смарт-контрактів

Ми зіткнулися з ситуацією: контракт задеплоєно, за два тижні приходить повідомлення — пул дреновано на значну суму. Дивимося транзакцію в Tenderly: атакуючий викликав deposit(), всередині callback на ERC-777 повторно викликав withdraw() — баланс оновився тільки після другого виходу. Класична reentrancy, але не через ETH transfer, а через хук ERC-777. ReentrancyGuard стояв тільки на withdraw().

Такі випадки — не рідкість. Смарт-контракт — це фінансова логіка без можливості пропатчити її вночі. Наша команда розробляє контракти під ключ, вбудовуючи захист від reentrancy, MEV та gas-атак на ранніх етапах. Reentrancy attack — одна з найпоширеніших вразливостей, що потребує глибокого розуміння EVM.

Як ми розробляємо смарт-контракти під ключ?

Починаємо з аудиту бізнес-логіки та вибору стеку. Solidity 0.8.x — стандарт для EVM-сумісних чейнів: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana використовуємо Rust та Anchor: модель акаунтів і програм вимагає явного оголошення всіх ресурсів. Для проектів з формальною верифікацією підходить Move (Aptos, Sui) — лінійні типи мови виключають копіювання ресурсів на рівні компілятора. Vyper обираємо для контрактів, де критична простота аудиту (Curve Finance).

Gas optimization — не передчасна оптимізація, а архітектурне рішення. На Ethereum mainnet деплой погано спроектованого контракту може коштувати значну суму тільки через неоптимальний storage layout. Переупаковка структури Proposal з 7 слотів до 4 заощадила 18k gas на кожному голосуванні — економія на масштабі протоколу з тисячами голосувань на день дає відчутну річну вигоду.

Типові помилки в gas: передача масивів через memory замість calldata в external функціях (дорожче в 2-3 рази); використання require з довгими рядками замість custom error error InsufficientBalance(...). Кастомні помилки дешевші на 50-200 gas на revert і передають структуровані дані фронтенду.

Чому аудит смарт-контрактів критичний для безпеки?

Аудит — не разова перевірка, а вбудований етап розробки. Використовуємо три рівні:

1. Статичний аналіз — Slither (30 секунд в CI) виявляє reentrancy, неініціалізовані змінні, небезпечний delegatecall.
2. Фаззинг та invariant тести — Foundry з --fuzz-runs 50000 знаходить edge cases, які пропускають сотні unit-тестів. Echidna перевіряє інваріанти («сума всіх балансів ≤ totalSupply»).
3. Ручний code review — наші інженери з досвідом 10+ років у блокчейні виявляють логічні помилки, які не ловлять інструменти. Для протоколів з високим TVL обов'язковий зовнішній аудит з боку Trail of Bits, Consensys Diligence або OpenZeppelin. Термін — 2-4 тижні.

Будь-який апгрейдуємий протокол повинен мати timelock. TimelockController з OpenZeppelin: операція пропонується → чекає мінімальний delay (48-72 години) → виконується. Без timelock один скомпрометований deployer wallet = втрата всього пулу.

OpenZeppelin Security Audits підтверджують, що 80% вразливостей, знайдених у деплоїних контрактах, пов'язані з відсутністю перевірок доступу або reentrancy. Ми включаємо ці перевірки в CI ще до першого деплою.

Які патерни апгрейду обираємо?

Storage collision — головна небезпека проксі. Implementation v2 не повинен додавати змінні перед існуючими. OpenZeppelin Upgrades plugin для Hardhat та Foundry перевіряє це автоматично, але тільки при використанні його API.

Як захистити контракт від MEV та front-running?

На Ethereum mainnet транзакції в mempool видно всім. MEV-боти проводять sandwich-атаки на DEX, фронтраннінги мінтингу та governance. Рішення: commit-reveal scheme для аукціонів, приватна відправка через Flashbots PROTECT RPC. EIP-7702 та PBS (proposer-builder separation) змінюють картину, але поки не масово.

Процес розробки

1. Аналітика — специфікація функцій, діаграма викликів, аналіз edge cases. Без цього кодинг починається даремно.
2. Розробка — Solidity/Rust з тестами паралельно. Тест → код → рефакторинг. Використовуємо Foundry для fuzz та invariant тестів.
3. Внутрішній аудит — Slither + Echidna + ручний code review. Foundry invariant tests для протокольних інваріантів.
4. Зовнішній аудит — для проектів з реальними грошима. Термін: 2-4 тижні.
5. Деплой — Foundry scripts або Hardhat Ignition з verify на Etherscan. Gnosis Safe для ownership transfer одразу після деплою.
6. Моніторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

Що входить в роботу

• Документація на архітектуру та специфікацію контракту (NatSpec).
• Вихідний код з репозиторієм та CI (Slither, Foundry, coverage).
• Розгорнута версія контракту з verify на блокчейн-експлорері.
• Результати аудиту (внутрішнього та зовнішнього за запитом).
• Доступи до моніторингу та управління (Gnosis Safe).
• Гарантія на код: фікси критичних багів протягом місяця після деплою.
• Консультація щодо інтеграції з веб-інтерфейсом (wagmi, RainbowKit).

Терміни орієнтовно

• ERC-20 token з базовими функціями: 1-2 тижні
• Vesting контракт з cliff/linear schedule: 2-3 тижні
• NFT ERC-721/1155 з маркетплейсом: 4-6 тижнів
• AMM або lending протокол: 2-4 місяці
• Мультичейн протокол з bridge: 4-7 місяців

Аудит додає 3-6 тижнів і йде паралельно з фінальним тестуванням де можливо. Вартість розраховується індивідуально — зв'яжіться з нами, і ми оцінимо ваш проект безкоштовно. Економія на газі завдяки нашій оптимізації може сягати 30% на рік для високонавантажених протоколів.

Зв'яжіться з нами для оцінки вашого проекту. Замовте розробку смарт-контракту — отримайте консультацію з архітектури та захисту від reentrancy, MEV та gas-атак. Напишіть нам — ми підберемо оптимальний стек під вашу задачу.