Разработка блокчейн-решений и Web3-приложений
Проект приходит с задачей: «Сделайте нам DeFi-протокол». За этим обычно скрывается минимум шесть независимых инженерных задач — смарт-контракты, фронтенд dApp, оракулы, индексация событий, инфраструктура нод и токеномика. Каждая из них решается своим стеком и имеет собственные точки отказа. Разберём, как это работает на практике. За 7 лет работы в блокчейне мы реализовали более 50 проектов — от простых NFT-коллекций до мультичейн DeFi-протоколов с TVL более $200M. Гарантируем безопасность кода и соответствие стандартам аудита.
Что входит в 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() проверял его повторно. Потери составили $1.4M до остановки протокола через 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 потерял $114M именно так.
Правильный подход — 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 от $100k получает timelock на апгрейды — минимум 48 часов. Это не перестраховка, это стандарт отрасли после серии атак на мгновенные апгрейды.
Сроки
- Простой ERC-20 с вестингом: 2–3 недели
- NFT-коллекция с маркетплейсом: 4–6 недель
- DeFi-протокол (lending или DEX): 3–6 месяцев включая аудит
- Полный Web3-продукт (контракты + фронтенд + инфраструктура): 4–9 месяцев
Стоимость рассчитывается индивидуально после технического брифинга. Свяжитесь с нами для консультации по вашему проекту — мы поможем оценить объём работ и сроки. Закажите разработку блокчейн-решений, защищённых от самых изощрённых атак.