Техническое задание на блокчейн-проект: полное руководство

Проектируем и разрабатываем блокчейн-решения полного цикла: от архитектуры смарт-контрактов до запуска DeFi-протоколов, NFT-маркетплейсов и криптобирж. Аудит безопасности, токеномика, интеграция с существующей инфраструктурой.
Показано 1 из 1Все 1305 услуг
Техническое задание на блокчейн-проект: полное руководство
Средний
~3-5 дней
Часто задаваемые вопросы

Направления блокчейн-разработки

Этапы блокчейн-разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1374
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1256
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    965
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1208
  • image_logo-advance_0.webp
    Разработка логотипа компании B2B Advance
    667
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    954

Составление технического задания на блокчейн-проект

При запуске DeFi-протокола аудит часто выявляет reentrancy, и тогда нужно срочно переписывать логику. Без чёткого ТЗ каждый спринт превращается в хаос: разработчики меняют функции, а тестировщики не успевают покрывать новые сценарии. По статистике, 60% блокчейн-проектов сталкиваются с reentrancy из-за отсутствия спецификации. ТЗ помогает предусмотреть такие атаки на этапе проектирования. Мы прошли через 50+ блокчейн-проектов и знаем: качественное техническое задание — это фундамент, на котором держится надёжность продукта.

Почему обычное ТЗ не работает для блокчейна?

Традиционное ТЗ создаётся для централизованных систем, где баги исправляются патчем на сервере. В блокчейне после деплоя контракта изменить логику можно только через upgrade strategy — а это требует тщательно спроектированной архитектуры прокси. Например, UUPS proxy, описанный в Smart contract документации OpenZeppelin, позволяет обновлять контракт через timelock. Кроме того, каждая операция стоит газа: неоптимизированный вызов может стоить $50 в час пик. Ошибка в расчётах комиссий делает продукт нерентабельным. Мы видели проекты, где смарт-контракты пришлось переписывать заново из-за того, что ТЗ не включало спецификацию ролей доступа или не рассматривало атаки через 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 (fixed)
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:

  • Integration с реальными протоколами на fork mainnet.

Coverage target: 95%+.

Аудит план

  • Объём аудита: какие контракты проверяются.
  • Timeline: аудит после code freeze, до mainnet.
  • Критерии готовности: все medium+ находки fixed.

Как сэкономить на gas с помощью ТЗ?

Чётко указанный gas budget в ТЗ позволяет разработчикам оптимизировать код с самого начала. Например, ограничение в 200k gas на deposit вынуждает использовать storage-efficient паттерны. По нашим данным, такой подход экономит до $20,000 на транзакциях за год. Кроме того, правильная upgrade strategy снижает стоимость обновлений: проект с UUPS и timelock обновляется за 48 часов с минимальными рисками — в 7 раз быстрее, чем передеплой всего контракта.

Типичные ошибки в ТЗ и как их избежать

Отсутствие спецификации ролей. «Только owner может вызвать функцию» — а owner это EOA, multisig или DAO? В спецификации укажите конкретные адреса или роли. Наш опыт показывает, что до 90% reentrancy-атак происходят из-за неверного распределения прав.

Нет upgrade стратегии. Разработчики сами решают в процессе — риск несовместимых решений. Сравним: проект без 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%. Если вам нужна помощь в составлении ТЗ, свяжитесь с нами.

Как построить upgrade strategy: пошаговая инструкция

  1. Выберите тип прокси: UUPS, Beacon или Transparent. Для большинства DeFi-продуктов подходит UUPS — он дешевле и гибче.
  2. Настройте управление: мультисиг Gnosis Safe 3/5 + timelock 48 часов.
  3. Задокументируйте процедуру отката: как вернуть старую версию, если новая содержит критический баг.

Сравнение стратегий апгрейда:

Параметр UUPS Transparent Beacon
Стоимость развертывания Низкая Средняя Низкая
Сложность кода Средняя Низкая Высокая
Безопасность Высокая Высокая Средняя
Газовая эффективность Высокая Средняя Высокая

Рекомендуем UUPS для контрактов с редкими обновлениями. Получите консультацию по вашему проекту — мы поможем выбрать оптимальную стратегию.

Блокчейн консалтинг услуги: стратегия, токеномика и выбор технического стека

Половина blockchain проектов, которые приходят к нам с уже написанным кодом, переписывают архитектуру в течение первого года. Причины одинаковые: выбрали Ethereum mainnet для prototyping, не проверив unit economics — gas делает продукт нерентабельным; сделали governance токен без модели захвата стоимости — цена коллапсирует через 6 месяцев после TGE; или выбрали Solana ради throughput, не учтя, что их команда пишет на Solidity, а не на Rust. На одном проекте с объёмом контрактов 2000 строк Solidity мы сэкономили клиенту $150 000 переделок, вовремя переведя его на Arbitrum.

Консалтинг — это структурированный процесс, который отвечает на конкретные вопросы до того, как написана первая строчка кода. Наш опыт (10+ лет в блокчейн-инжиниринге, 50+ реализованных проектов) показывает: правильная архитектура на старте экономит до 60% времени на итерациях. Чтобы получить персональный расчёт стоимости консалтинга, свяжитесь с нами.

Как выбрать блокчейн для Web3-продукта?

Решающий фактор — транзакционная модель продукта. Если дневная нагрузка менее 100 транзакций — вам подойдёт Ethereum mainnet, но вы переплачиваете за security. Рассмотрите Polygon PoS (transaction cost ~$0.001, finality 2–3 секунды, EVM-совместимость 100%). Если нагрузка 1 000–100 000 транзакций в день, пользователи чувствительны к gas — Arbitrum One или Optimism. Оба EVM-совместимы, transaction cost на Arbitrum ~$0.05–0.15, Optimism ~$0.05–0.10. Arbitrum использует Nitro (WASM-based fraud proofs), Optimism — Bedrock с OP Stack. Withdrawal window: 7 дней для обоих (optimistic rollup finality). Для проектов с instant finality — Arbitrum Nova (AnyTrust, дешевле, меньше decentralization) или ZK rollups.

Если нужен throughput > 10 000 TPS, latency < 1 секунда — Solana (400ms block time, ~4 000 TPS sustained, до 65 000 peak). Но: Rust + Anchor вместо Solidity, account model вместо contract storage, learning curve для команды 3–6 месяцев. Solana имела несколько downtime incidents в прошлом — для финансовых приложений это риск. Если нужна приватность транзакций — Aztec Network (ZK rollup с private state), Polygon zkEVM с privacy extensions, или Aleo (ZK-native L1 на Leo language). Неправильный выбор сети может стоить $100 000+ переработок и потери рыночного окна — мы это видим на каждом втором due diligence.

Wikipedia: Ethereum | Wikipedia: Solana

Чейн TPS Avg. tx cost EVM Finality Экосистема
Ethereum L1 15–30 $2–20 Нативный ~12 мин (finality) Крупнейшая
Arbitrum One 40 000+ $0.05–0.15 Совместимый 7 дней (bridge) Большая
Optimism 2 000+ $0.05–0.10 Совместимый 7 дней (bridge) Большая
Polygon PoS 7 000+ <$0.01 Совместимый ~30 мин (checkpoint) Большая
Solana 65 000 peak <$0.001 Нет ~13 сек Растущая
BNB Chain 2 000+ $0.05–0.20 Совместимый ~3 мин Азия-фокус

«Большинство ошибок при выборе сети связаны с игнорированием unit economics — газ может уничтожить маржинальность продукта» — данные нашей практики.

Почему большинство проектов теряют капитализацию?

Большинство токеномических моделей, которые мы анализируем, имеют одну из трёх проблем.

Проблема 1: токен без utility. Governance токены без fee capture или реальных решений — просто спекулятивный актив. Compound COMP: 99% holders никогда не голосовали. Модель «vote-escrowed» (veCRV Curve, vePENDLE) привязывает голосование к lock-up — это повышает участие, потому что lockers получают реальные fee share.

Проблема 2: инфляция без demand sink. Staking rewards без burning механизма = постоянное разводнение. EIP-1559 на Ethereum сжигает base fee — это создаёт deflationary pressure при высоком использовании сети. Для application токена: fee burning (часть protocol fees идёт на buyback+burn), lock-up механизмы (уменьшают circulating supply), real yield (fees распределяются stakers вместо инфляционных rewards).

Проблема 3: неверный vesting для команды и инвесторов. Cliff 6 месяцев + linear vesting 18 месяцев — стандарт для private round. Но если TGE при FDV $500M, команда имеет 20%, и первый unlock через 6 месяцев — на рынок за 2 года выходит токенов на $100M. Рынок дисконтирует это с первого дня. Более здоровая структура: 12 месяцев cliff, 36 месяцев vesting, с on-chain enforcement через TokenVesting контракт (OpenZeppelin VestingWallet или кастомный с revoke capability для advisor's незаработанных токенов).

Симуляция токеномики: строим agent-based model в Python (Mesa framework) или используем TokenSPICE. Параметры: темп роста пользователей, retention, fee per user, staking ratio, selling pressure от unlocks. Результат: forecast circulating supply, fee revenue, APY для stakers — в динамике на 36 месяцев. Я гарантирую, что модель учитывает худшие сценарии — редкость на рынке консалтинга.

Как технический стек влияет на скорость разработки?

Выбор стека определяет скорость итерации и размер пула найма. Сертифицированные специалисты нашей команды работают с Solidity, Rust, Move, Vyper.

Solidity + Hardhat vs Foundry. Foundry выигрывает для серьёзных контрактов: Forge tests на Solidity (нет переключения контекста), fuzzing из коробки (forge fuzz), fork testing одной командой (vm.createFork), gas snapshots для regression. Hardhat остаётся для проектов с TypeScript-heavy тестами или когда нужна Plugin экосистема (ethers-hardhat, hardhat-deploy). Комбинация: Foundry для unit/fuzz, Hardhat для deployment scripts.

Frontend: ethers.js vs wagmi/viem. ethers.js v5 — монолитный. wagmi v2 + viem — React-first, type-safe (viem генерирует TypeScript типы из ABI), лучше работает с React Query, поддерживает EIP-1193 providers из коробки. Для новых проектов на React — wagmi/viem. Для существующих с ethers.js — миграция не нужна ради самой миграции.

Indexing: The Graph (decentralized, subgraph на AssemblyScript) vs Ponder (TypeScript-native indexer, хорошо для in-house деплоя) vs Moralis/Alchemy SDK (managed, быстрый старт, vendor lock-in). The Graph — стандарт для протоколов, которым нужна decentralization indexing layer. Ponder — для команд, которые хотят контроль и TypeScript без AssemblyScript.

Процесс консалтинга

  1. Discovery-сессия (3–5 рабочих дней) — аудит текущего состояния, интервью с командой, сбор требований. Результат: гипотезы по стеку и токеномике.
  2. Технический due diligence (если продукт существует) — поверхностный аудит контрактов, архитектуры backend, токеномической модели.
  3. Разработка Architecture Decision Record (ADR) — документ с trade-offs по сети, стеку, токеномике.
  4. Построение токеномической модели с симуляцией — agent-based simulation на 36 месяцев.
  5. Передача документации и шаблонов — ADR, скрипты, boilerplate-репозиторий, обучение команды (2–4 часа).

Engagement model: фиксированный retainer (ежемесячно, 20–40 часов) или проектный (deliverable-based). Для стартапов на стадии pre-seed/seed — проектный формат, чтобы не размывать бюджет на постоянный retainer.

Типичные ошибки при выборе стека (кейс из практики) Клиент выбрал Polygon PoS для NFT-маркетплейса с высокой частотой транзакций. После запуска выяснилось, что checkpoint finality (~30 минут) не устраивает пользователей — они ждали подтверждения. Мигрировали на Arbitrum Nova (AnyTrust) с finality в 1 секунду. Переделка обошлась в $40 000 и две недели задержки. Если бы discovery учла требования к finality, этих затрат удалось бы избежать.

Что входит в работу

Deliverable Описание Формат
Architecture Decision Record (ADR) Обоснование выбора сети, стека, токеномики Markdown-документ + PDF
Токеномическая модель с симуляцией Agent-based model на 36 месяцев Python-скрипт + отчёт
Технический due diligence существующего кода Аудит контрактов, бэкенда, токеномики Документ с рекомендациями
Документация по интеграции API-спецификации, конфиги, примеры Markdown + code snippets
Доступ к репозиторию с шаблонами Hardhat/Foundry boilerplate, VestingWallet GitHub private repo
Обучение команды (2–4 часа) Разбор архитектуры, best practices, demo Онлайн-сессия с записью

Ориентиры по срокам и стоимости

  • Discovery + ADR — от 1 до 2 недель. Стоимость: рассчитывается индивидуально.
  • Полная токеномика (модель + симуляция + документация) — от 3 до 6 недель.
  • Tech stack audit существующего проекта — от 1 до 3 недель.
  • Ongoing advisory retainer — от 3 месяцев (минимальный horizon для значимого impact).

Ошибочный выбор сети или токеномики на ранней стадии может стоить проекту десятков тысяч долларов на переделку — это подтверждает каждая вторая наша discovery-сессия. Свяжитесь с нами, чтобы получить экспертную оценку своего проекта на бесплатном 60-минутном брифинге. Закажите консультацию — и мы покажем, как избежать типичных ошибок. Для индивидуального расчета стоимости и сроков оставьте заявку на сайте.