Розробка блокчейн-рішень та Web3-додатків
Проект приходить із завданням: «Зробіть нам DeFi-протокол». За цим зазвичай ховається щонайменше шість незалежних інженерних завдань — смарт-контракти, фронтенд dApp, оракули, індексація подій, інфраструктура нод та токеноміка. Кожне з них вирішується своїм стеком і має власні точки відмови. Розберемо, як це працює на практиці. За 7 років роботи в блокчейні ми реалізували понад 50 проектів — від простих NFT-колекцій до мультичейн DeFi-протоколів з великим TVL. Гарантуємо безпеку коду та відповідність стандартам аудиту.
Що входить у Web3-розробку?
Блокчейн-проект — це не просто «написати Solidity». Типовий продакшн-стек виглядає так:
| Шар | Технології | Основні ризики |
|---|---|---|
| Смарт-контракти | Solidity, Rust (Anchor), Move, Vyper | reentrancy, overflow, oracle manipulation |
| Тестування та аудит | Foundry, Hardhat, Slither, Echidna | false negative в unit-тестах |
| Фронтенд dApp | React + wagmi + viem + RainbowKit | UX wallet flow, chain switching |
| Індексація даних | The Graph, Ponder, subgraphs | затримка даних, реоргі |
| Інфраструктура | Alchemy, QuickNode, власні ноди | RPC rate limits, downtime |
| Токеноміка | ERC-20 + vesting + governance | інфляційний тиск, атаки на governance |
Кожен шар можна замовити окремо або в комплексі. Більшість клієнтів приходять або з уже написаними контрактами, які потрібно перевірити та розгорнути, або з ідеєю продукту, яку потрібно перетворити на робочий протокол з нуля.
Смарт-контракти: де концентрується ризик
Основна частина бюджету та часу в Web3-проектах йде на контракти — і не без причини. Код смарт-контракту керує реальними грошима напряму, без проміжного сервера, який можна виправити вночі.
Reentrancy та cross-function атаки
Класична reentrancy стала хрестоматійною після The DAO, але варіанти продовжують з'являтися. Більш підступна версія — cross-function reentrancy, коли ReentrancyGuard від OpenZeppelin не допомагає: атакуючий входить через одну функцію, яка не захищена гардом, і маніпулює станом, який читає інша.
Приклад з недавнього аудиту: lending-протокол на Arbitrum використовував nonReentrant на withdraw(), але не на liquidate(). Flash loan дозволяв атакуючому викликати liquidate() всередині callback, змінити collateral ratio до того, як withdraw() перевіряв його повторно. Втрати були значними до зупинки протоколу через multisig.
Правильний підхід — checks-effects-interactions паттерн плюс глобальний м'ютекс на рівні протоколу, а не на рівні окремих функцій. Детальніше про смарт-контракти.
Storage collision у proxy-паттернах
Upgradeable контракти через UUPS або Transparent Proxy — стандарт для продакшн-протоколів. Але storage layout між implementation та proxy має збігатися точно. Одна змінна, додана на початок нового implementation, зсуває всі слоти та перезаписує дані існуючих користувачів.
OpenZeppelin надає @openzeppelin/upgrades-plugins для Hardhat та Foundry, який перевіряє storage layout при апгрейді. Але плагін не врятує, якщо розробник вручну керує слотами через assembly — тут потрібен ручний аудит layout-у.
Gas griefing та unbounded loops
Контракти з for (uint i = 0; i < users.length; i++) над динамічним масивом — це газова бомба. При досить великому масиві транзакція не вміщується в блок взагалі. Бачили проекти, де governance-голосування блокувалося через те, що масив учасників виріс до 50k адрес, а distribute-функція проходила по всіх в одній транзакції.
Рішення — паттерн pull-over-push: користувачі самі забирають винагороди, не отримують їх пушем. Або pagination зі збереженням checkpoint у storage.
DeFi та оракули: як уникнути втрат?
DeFi-протокол — це система взаємозалежних контрактів. Точки інтеграції між ними — головний вектор атак.
Oracle manipulation
Цінові оракули на основі spot price з Uniswap v2 — відома вразливість. Flash loan дозволяє за одну транзакцію зсунути spot price в пул, взяти кредит під завищений collateral та повернути flash loan, залишившись з прибутком. Це не теорія: Mango Markets втратив значні кошти саме так.
Правильний підхід — Chainlink Price Feeds з TWAP (time-weighted average price) або Uniswap v3 TWAP через observe(). TWAP складніше маніпулювати, тому що потрібно утримувати ціну кілька блоків, що дорого.
Concentrated liquidity та impermanent loss
AMM на Uniswap v3 з концентрованою ліквідністю вимагає грамотного управління позиціями. LP-токени ERC-721 замість ERC-20 означають, що стандартні vault-паттерни для компаундингу не працюють напряму — потрібні адаптери типу Arrakis або власна логіка управління ranges.
NFT, фронтенд та інфраструктура: ключові компоненти
ERC-721 та ERC-1155 — базові стандарти. Складність починається з динамічних NFT: метадані зберігаються on-chain через base64-encoded SVG або off-chain через IPFS з можливістю апдейту. Marketplace royalties через ERC-2981 — стандарт, але OpenSea реалізує його по-своєму, Blur ігнорував його до недавнього часу. Це потрібно враховувати при проектуванні royalty-механіки.
Wagmi v2 + viem — поточний стандарт для TypeScript dApps. RainbowKit або ConnectKit закривають UX wallet connection. Головна складність — мультичейн: користувач може бути на Ethereum Mainnet, а контракт задеплоєно на Arbitrum. Обробка chain switching, pending транзакцій та rejected підписів без втрати state — це окрема інженерна задача.
Власні ноди дають контроль над RPC та відсутність rate limits, але вимагають DevOps-підтримки. Для більшості проектів Alchemy або QuickNode з архівною нодою достатньо. The Graph Protocol для індексації подій — стандарт: субграф описує mapping handlers на AssemblyScript та індексує події в PostgreSQL-сумісне сховище з GraphQL API.
Токени: ERC-20, вестинг, governance
ERC-20 з базовими функціями пишеться за день. Складність — у tokenomics: vesting schedules з cliff, liquidity bootstrapping через Balancer LBP або Fjord Foundry, governance через OpenZeppelin Governor або Compound-style bravo. Кожен з цих компонентів має власні attack vectors — vote delegation manipulation, flash loan governance attacks, frontrunning на vesting claim.
Стек та інструменти
Контракти: Solidity 0.8.x, Rust + Anchor (Solana), Move (Aptos/Sui). Тестування: Foundry (fuzz, invariant tests) — Foundry виконує fuzz-тести в 10 разів швидше, ніж Hardhat, Hardhat (інтеграційні), Slither (статичний аналіз), Echidna (property-based fuzzing). Бібліотеки: OpenZeppelin Contracts 5.x, Solmate, PRBMath. Фронтенд: React 18 + TypeScript, wagmi v2, viem, RainbowKit, ethers.js. Інфраструктура: The Graph, Alchemy, QuickNode, Infura. Деплой: Foundry scripts, Hardhat Ignition, Gnosis Safe для multisig.
Процес роботи
Аналітика вимог → архітектура контрактів та схема взаємодій → розробка з покриттям тестами → внутрішній аудит через Slither + Echidna → зовнішній аудит (при необхідності) → деплой на testnet → mainnet з multisig timelock → підтримка моніторингу через Tenderly або OpenZeppelin Defender.
Кожен протокол зі значним TVL отримує timelock на апгрейди — мінімум 48 годин. Це не перестраховка, це стандарт галузі після серії атак на миттєві апгрейди.
Терміни
- Простий ERC-20 з вестингом: 2–3 тижні
- NFT-колекція з маркетплейсом: 4–6 тижнів
- DeFi-протокол (lending або DEX): 3–6 місяців включаючи аудит
- Повний Web3-продукт (контракти + фронтенд + інфраструктура): 4–9 місяців
Вартість розраховується індивідуально після технічного брифінгу. Зв'яжіться з нами для консультації по вашому проекту — ми допоможемо оцінити обсяг робіт та терміни. Замовте розробку блокчейн-рішень, захищених від найвитонченіших атак.