Рефакторинг смарт-контрактів
Контракт працює, гроші не втрачає — але кожен новий feature викликає паніку. Storage layout роздувся, функції на 200 рядків, тестів немає. Наш досвід показує, що такий технічний борг накопичується непомітно, поки не призводить до критичних збоїв або втрати gas. Ми гарантуємо: після рефакторингу код стане передбачуваним і безпечним.
Де найчастіше ховається технічний борг
Неоптимізований storage layout
Solidity пакує змінні в 32-байтні слоти. Якщо змінні оголошені в порядку uint128, uint256, uint128 — це три слоти замість двох. На контракті з тисячами викликів на день переупорядкування 8 змінних під slot packing знизило gas на write-операції на 40%. Економія — до $5000 на рік на користувачах. Це конкретні гроші, які йдуть на газ.
Unbounded loops як gas griefing
Паттерн for (uint i = 0; i < users.length; i++) в контракті, де users може зростати — це не просто неефективність. Зловмисник додає 10 000 адрес, і виклик distribute() вилітає за ліміт блоку (30M gas). Функція стає невиконуваною — contract stuck. Рефакторинг на pull-паттерн з пагінацією вирішує це структурно.
Cross-function reentrancy
ReentrancyGuard від OpenZeppelin захищає одну функцію. Але якщо withdraw() захищений guard, а claim() ні — і обидві змінюють один balance mapping — reentrancy можливий. Так працював експлойт на 80M$. При рефакторингу аудируємо весь граф викликів, а не тільки окремі функції.
Як ми підходимо до рефакторингу
Перший крок — статичний аналіз через Slither. Він за 2-3 хвилини знаходить reentrancy, неініціалізовані змінні, tx.origin авторизацію, shadow variables. Slither дає сотні warning-ів — важливо відсіяти критичні від інформаційних. Далі — Mythril для символічного виконання на ключових функціях.
Ось покроковий процес роботи:
- Аналіз: статичний та символічний аналіз (Slither, Mythril), складання реєстру проблем з пріоритетами.
- Планування: групування змін, ізоляція залежностей, написання тестів для edge cases.
- Рефакторинг: кожна зміна в окремому PR з тестами. Застосовуємо Solidity best practices, Check-Effects-Interactions, Diamond pattern (EIP-2535).
- Тестування: fuzz-тести в Foundry, порівняння gas звіту
forge snapshot. - Розгортання: скрипти на ethers.js, моніторинг через Tenderly.
Приклад: рефакторинг стейкінг-пулу
На одному проєкті ми замінили unbounded loop на pull-паттерн з пагінацією. Додали флаг emergencyWithdraw для безпечного виходу при DoS. Впровадили custom errors замість строкових require — економія 100 gas на reVERT. Результат: функція distribute стала виконуваною навіть при зростанні користувачів до 50 000, а загальна економія газу досягла 15%.
Чому рефакторинг смарт-контракту дешевший за аудит?
Аудит виявляє проблеми, але не виправляє їх. Рефакторинг одразу усуває технічний борг. Ми не просто пишемо звіт — ми переписуємо код так, щоб він був безпечним і gas-ефективним. Типовий аудит коштує $10-30k, а рефакторинг з виправленнями — ту саму суму, але з готовим кодом. Зв'яжіться з нами — ми оцінимо ваш проєкт і запропонуємо план робіт.
Gas optimization: конкретні цифри
| Паттерн | Економія gas (приблизно) |
|---|---|
| Slot packing змінних | 20-40% на SSTORE |
| memory замість storage в функції | 15-30% на читання |
| unchecked increment | 60-80 gas на ітерацію |
| calldata замість memory | 50-100 gas на аргумент |
| Custom errors замість require strings | 50-200 gas на revert |
Типові проблеми та рішення
| Проблема | Рішення | Економія/вигода |
|---|---|---|
| Reentrancy через декілька функцій | Повний граф викликів + OpenZeppelin ReentrancyGuard | Запобігання втратам до $80M |
| Storage layout неоптимальний | Переупорядкування змінних, pack | $5000/рік економії газу |
| Unbounded loops | Pull-паттерн з пагінацією | Гарантія виконуваності функції |
Що входить в роботу
- Аудит коду з реєстром вразливостей та optimization-можливостей.
- Виправлення всіх критичних та середніх проблем.
- Тести на Foundry (unit, integration, fuzz).
- Порівняння gas звіту до/після.
- Документація змін та інструкція по деплою.
- Гарантія на код — 6 місяців підтримки.
Які помилки найчастіше допускають при рефакторингу?
- Виправляють лише очевидні проблеми, не перевіряючи cross-function reentrancy.
- Змінюють ABI без ізоляції — ламають інтеграції.
- Забувають оновити тести після змін.
- Спрощують storage layout, але не враховують успадковані контракти.
Наші інженери з досвідом 10+ років у блокчейн-розробці пройшли понад 50 проєктів рефакторингу. Отримайте консультацію — ми розповімо, що потрібно виправити саме у вашому контракті.
Апгрейд Solidity версії
Міграція з 0.6/0.7 на 0.8+ включає: автоматичні перевірки overflow (SafeMath більше не потрібен), custom errors, immutable змінні. Але це не просто зміна pragma — ABI encoding змінюється, assembly-паттерни вимагають адаптації. Тестуємо кожну зміну ізольовано.
OpenZeppelin ReentrancyGuard — стандарт безпеки, який ми використовуємо як базовий. Зв'яжіться з нами — ми оцінимо ваш проєкт і запропонуємо рефакторинг під ключ.