Складання технічного завдання на блокчейн-проєкт
При запуску DeFi-протоколу аудит часто виявляє reentrancy, і тоді потрібно терміново переписувати логіку. Без чіткого ТЗ кожен спринт перетворюється на хаос: розробники змінюють функції, а тестувальники не встигають покривати нові сценарії. За статистикою, 60% блокчейн-проєктів стикаються з reentrancy через відсутність специфікації. ТЗ допомагає передбачити такі атаки на етапі проєктування. Ми маємо понад 5 років досвіду в блокчейн-розробці та провели 50+ проєктів — якісне технічне завдання це фундамент, на якому тримається надійність продукту.
Чому звичайне ТЗ не працює для блокчейну?
Традиційне ТЗ створюється для централізованих систем, де баги виправляються патчем на сервері. У блокчейні після деплою контракту змінити логіку можна тільки через upgrade strategy — а це вимагає ретельно спроєктованої архітектури проксі. Наприклад, UUPS proxy, описаний у Smart contract документації OpenZeppelin, дозволяє оновлювати контракт через timelock. Крім того, кожна операція коштує газу: неоптимізований виклик може коштувати $50 в годину пік, а правильний gas budget згідно з ТЗ зекономить до $20,000 на рік. Помилка в розрахунках комісій робить продукт нерентабельним. Ми бачили проєкти, де смарт-контракти довелося переписувати заново через те, що ТЗ не включало специфікацію ролей доступу або не розглядало атаки через flash loan.
Які розділи повинно містити технічне завдання на блокчейн-проєкт?
Огляд системи
- Мета проєкту та ключові stakeholders.
- Обраний блокчейн (L1/L2) та обґрунтування: Ethereum, Polygon, Arbitrum або Solana.
- Високорівнева архітектура з diagram — взаємодія контрактів, off-chain компонентів.
- Інтеграції: оракули (Chainlink), bridge, зовнішні протоколи.
Як прописати смарт-контракти в ТЗ?
Кожен контракт вимагає детального опису: сигнатури функцій з параметрами, генеровані події, ролі доступу (AccessControl), налаштовувані параметри. Важливо вказати стандарти (ERC-20, ERC-721, ERC-1155, ERC-4626) та тип проксі. Наводимо приклад для контракту пулу ліквідності:
Приклад специфікації контракту пулу ліквідності
Contract: LiquidityPool Мережа: Arbitrum One Стандарти: ERC-20 compatible Апгрейд: UUPS proxy Функції: - deposit(uint256 amount) — депозит токенів, mint LP shares - withdraw(uint256 shares) — burn LP shares, отримати токени + accumulated fees - swap(address tokenIn, uint256 amountIn, uint256 minAmountOut) — обмін Події (Events): - Deposit(address indexed user, uint256 amount, uint256 shares) - Withdraw(address indexed user, uint256 shares, uint256 amount) - Swap(address indexed user, address tokenIn, uint256 amountIn, uint256 amountOut) Ролі (Access Control): - DEFAULT_ADMIN_ROLE: Gnosis Safe 3/5 - PAUSE_ROLE: Protocol Defender (multisig або automated) - FEE_MANAGER_ROLE: DAO timelock Параметри (configurable): - swapFee: 0.3% (range: 0.01%-1%) - protocolFeeShare: 20% від swap fee Приклад специфікації контракту пулу ліквідності: вище наведено повний шаблон — заповніть його для кожного контракту. Вкажіть gas budget: наприклад, max gas per deposit = 200k gas. Це запобіжить неочікуваним витратам після деплою.
Токен специфікація (якщо є)
Token: PROTO Standard: ERC-20 + ERC-2612 (Permit) Supply: 100,000,000 (фіксований) Decimals: 18 Mintable: ні (fixed supply) Burnable: так (holder може спалити) Pausable: так (PAUSE_ROLE) Distributor: спеціальний Vesting контракт Off-chain компоненти
- Indexer (The Graph subgraph) — які події індексуються, GraphQL схема.
- Backend API (якщо потрібен) — endpoints, authentication.
- Frontend — технічний стек, wallet інтеграція (wagmi, RainbowKit).
Інфраструктура
Деплой: - Foundry Deploy Scripts + Hardhat для верифікації - Multisig owner: Gnosis Safe 3/5 - Timelock: 48 годин для admin функцій - Proxy: UUPS (implementation upgrade через timelock) Моніторинг: - OpenZeppelin Defender для alerts - Tenderly для транзакцій simulation - The Graph для історичних даних Мережі для деплою: - Testnet: Arbitrum Sepolia - Mainnet: Arbitrum One Безпека
- Список smart contract патернів: Reentrancy guard, CEI, перевірки oracle manipulation.
- Захист від flash loan attack: перевірка балансу пулу до та після swap.
- Access control схема: кожна роль прив'язана до конкретної адреси (EOA, multisig, DAO).
- Upgrade strategy з timelock: процес ініціювання та відкату.
Тестування
Unit tests (Foundry):
- Всі публічні функції.
- Edge cases та boundary conditions.
- Revert scenarios.
Fuzz tests:
- Інваріанти: "totalShares * pricePerShare = totalAssets".
- Random deposit/withdraw sequences.
Fork tests:
- Інтеграція з реальними протоколами на fork mainnet.
Coverage target: 95%+.
Аудит план
- Обсяг аудиту: які контракти перевіряються.
- Timeline: аудит після code freeze, до mainnet.
- Критерії готовності: всі medium+ знахідки fixed.
Економія на gas за допомогою ТЗ
Чітко вказаний gas budget в ТЗ дозволяє розробникам оптимізувати код з самого початку. Наприклад, обмеження в 200k gas на deposit змушує використовувати storage-efficient патерни. За нашими даними, такий підхід економить до $20,000 на транзакціях за рік. Для порівняння: використання UUPS замість Transparent proxy знижує витрати на газ на 50% завдяки меншому розміру проксі. Крім того, правильна upgrade strategy знижує вартість оновлень: проєкт з UUPS та timelock оновлюється за 48 годин — це в 7 разів швидше, ніж передеплой всього контракту. Ми гарантуємо, що ваше ТЗ покриває всі аспекти безпеки та оптимізації, що підтверджено нашим досвідом 50+ проєктів.
Типові помилки в ТЗ та як їх уникнути
Відсутність специфікації ролей. «Тільки owner може викликати функцію» — а owner це EOA, multisig чи DAO? У специфікації вкажіть конкретні адреси або ролі. Наш досвід показує, що до 90% reentrancy-атак відбуваються через неправильний розподіл прав.
Немає upgrade strategy. Розробники самі вирішують в процесі — ризик несумісних рішень. Порівняємо: проєкт без upgrade strategy при помилці вимагає повного передеплою, що веде до втрати ліквідності та довіри. Проєкт з UUPS та timelock оновлюється за 48 годин з мінімальними ризиками.
Не вказано цільовий gas budget. Контракт написаний, потім виявляється що кожен виклик коштує $50 gas. Вказуйте бюджет в ТЗ: наприклад, max gas per deposit = 200k gas (для Solidity 0.8.20). Це дозволить зекономити до $20,000 на транзакціях за рік. Недостатня специфікація також призводить до додаткових витрат на аудит у розмірі $5,000–$10,000.
Не описані failure scenarios. Що відбувається якщо оракул недоступний, якщо контрагент не імплементує інтерфейс? Пропишіть всі альтернативні шляхи та механізми паузи.
Що входить у складання ТЗ під ключ?
| Розділ | Опис | Тривалість |
|---|---|---|
| Аналіз вимог | Інтерв'ю з замовником, вивчення конкурентів, специфікація бізнес-логіки | 3-5 днів |
| Архітектурне проектування | Вибір L2, стеку, патернів контрактів, upgrade strategy | 2-4 дні |
| Специфікація смарт-контрактів | Функції, події, ролі, gas budget, тестові сценарії | 4-7 днів |
| Опис off-chain | Indexer, backend, frontend, інтеграції з Chainlink, bridge | 2-3 дні |
| Інфраструктура та моніторинг | Deploy scripts, Defender alerts, Tenderly simulation | 1-2 дні |
| Підсумкова документація | Зведена таблиця, чек-лист для розробників, план тестування та аудиту | 1-2 дні |
Весь процес займає від 1 до 4 тижнів залежно від складності. Після здачі ТЗ ви отримуєте документ, який можна передати будь-якій команді розробників — він скорочує час code review та аудиту на 30%. Для будь-якого криптопроекту чи децентралізованого додатку (DeFi, NFT, web3) важливо мати чітке ТЗ. Якщо вам потрібна допомога в складанні ТЗ, зв'яжіться з нами.
Як побудувати upgrade strategy: покрокова інструкція
- Виберіть тип проксі: UUPS, Beacon або Transparent. Для більшості DeFi-продуктів підходить UUPS — він дешевший і гнучкіший.
- Налаштуйте управління: мультисиг Gnosis Safe 3/5 + timelock 48 годин.
- Задокументуйте процедуру відкату: як повернути стару версію, якщо нова містить критичний баг.
Порівняння стратегій апгрейду:
| Параметр | UUPS | Transparent | Beacon |
|---|---|---|---|
| Вартість розгортання | Низька | Середня | Низька |
| Складність коду | Середня | Низька | Висока |
| Безпека | Висока | Висока | Середня |
| Газова ефективність | Висока | Середня | Висока |
Рекомендуємо UUPS для контрактів з рідкісними оновленнями. Ми маємо сертифікованих аудиторів, які перевірять вашу стратегію. Отримайте консультацію по вашому проєкту — ми допоможемо вибрати оптимальну стратегію.







