Проектирование архитектуры dApp: от смарт-контрактов до UX

Проектирование архитектуры dApp

Недавно к нам обратилась команда DeFi-протокола: их фронтенд делал 20 отдельных RPC-вызовов при каждой загрузке страницы, что приводило к задержке в 5–7 секунд. Проблема была в том, что смарт-контракты не были спроектированы с учётом frontendability: отсутствовали view-функции и богатые Events. Мы перепроектировали архитектуру, добавили Multicall3 и снизили количество запросов до одного — время загрузки упало до 400 мс. Проектирование dApp начинается не с выбора фреймворка, а с анализа того, как пользователь будет взаимодействовать с приложением. Типичная ошибка — разрабатывать фронтенд в отрыве от контрактов. Мы гарантируем, что каждый слой — от смарт-контрактов до UX-потоков — работает как единое целое.

Как мы проектируем безопасную архитектуру dApp?

Первый шаг — выбор стандартов и паттернов для смарт-контрактов. Используем Solidity 0.8.x с защитой от переполнения, явные require и revert с сообщениями, а также проверенные библиотеки (OpenZeppelin). Каждый контракт аудируем статическим анализатором Slither и fuzzer'ом Echidna. Это снижает риск reentrancy, flash loan атак и других уязвимостей. Типичная экономия газа после оптимизации — 30–50% по сравнению с наивной реализацией.

Почему frontendability критична для DeFi?

Контракты должны быть удобны для фронтенда. Это значит:

• Богатые Events для каждого значимого действия (перевод, изменение баланса, смена параметров).
• View-функции для чтения без газа (например, totalAssets, balanceOf).
• Совместимость с Multicall3 — чтобы фронтенд мог получать десятки значений за один RPC-запрос.

Data fetching архитектура

Мы используем многоуровневую систему загрузки данных:

• Realtime: WebSocket к RPC или Alchemy SDK.
• Recent history: The Graph (subgraph).
• Historical analytics: Self-hosted PostgreSQL indexer.
• Prices: CoinGecko API + Chainlink on-chain.

По данным документации The Graph, субграфы могут обрабатывать до 1000 событий в секунду. Для одного из клиентов мы настроили индекс, который за 2 минуты обрабатывал 3 миллиона событий.

Как мы реализуем transaction flow UX?

Пользовательский опыт при отправке транзакции — частый источник ошибок. Мы проектируем четыре состояния:

• IDLE: кнопка готова.
• WAITING_WALLET: пользователь подтверждает в кошельке.
• CONFIRMING: транзакция в мемпуле.
• SUCCESS или ERROR: финальное состояние.

Пример с wagmi:

function DepositButton({ amount }: { amount: bigint }) {
  const { data: hash, writeContract, isPending } = useWriteContract();
  const { isLoading: isConfirming, isSuccess } = useWaitForTransactionReceipt({ hash });
  
  const status = isPending ? "WAITING_WALLET" 
               : isConfirming ? "CONFIRMING" 
               : isSuccess ? "SUCCESS" 
               : "IDLE";
  
  return (
    <button
      onClick={() => writeContract({ address: POOL, abi, functionName: "deposit", args: [amount] })}
      disabled={status !== "IDLE"}
    >
      {status === "WAITING_WALLET" && "Confirm in wallet..."}
      {status === "CONFIRMING" && "Confirming..."}
      {status === "SUCCESS" && "Deposited!"}
      {status === "IDLE" && "Deposit"}
    </button>
  );
}

State management и batching

Для чтения данных используем TanStack Query с refetchInterval (30 секунд для чувствительных данных) и Multicall3 для объединения запросов:

import { multicall } from "viem/actions";

const results = await multicall(client, {
  contracts: [
    { address: TOKEN_A, abi: ERC20_ABI, functionName: "balanceOf", args: [user] },
    { address: TOKEN_B, abi: ERC20_ABI, functionName: "balanceOf", args: [user] },
    { address: POOL, abi: POOL_ABI, functionName: "totalAssets" },
  ],
});

Wallet connection

Настраиваем RainbowKit с поддержкой основных сетей и кошельков:

import { getDefaultConfig, RainbowKitProvider } from "@rainbow-me/rainbowkit";
import { arbitrum, mainnet, base } from "wagmi/chains";

const config = getDefaultConfig({
  appName: "MyDApp",
  projectId: WALLETCONNECT_PROJECT_ID,
  chains: [mainnet, arbitrum, base],
  wallets: [
    { groupName: "Popular", wallets: [metaMaskWallet, coinbaseWallet, walletConnectWallet] },
  ],
});

Сравнение подходов к архитектуре

Сравнение методов индексации

Процесс работы над проектом

1. Аналитика — изучение бизнес-логики, пользовательских сценариев.
2. Проектирование — контрактная архитектура, спецификация событий, data flow диаграммы.
3. Реализация — написание контрактов (Solidity/Rust), фронтенда (React + wagmi + RainbowKit), indexer'ов.
4. Тестирование — unit-тесты (Foundry), fuzzing, интеграционные тесты (Tenderly, Hardhat).
5. Деплой — развёртывание с verify на Etherscan, настройку Tenderly Dashboard.
6. Поддержка — мониторинг транзакций, обновление контрактов через proxy, оптимизация газа.

Сроки и что входит в работу

Сроки: от 2 до 6 недель в зависимости от сложности. Стоимость рассчитывается индивидуально — свяжитесь с нами, чтобы получить оценку. Входит:

• Архитектурная документация (схемы, спецификации).
• Исходный код контрактов с комментариями.
• Фронтенд-стек с конфигурацией (wagmi, RainbowKit).
• Доступы к Tenderly проекту и алерты.
• Обучение команды работе с кодом.

Типичные ошибки при проектировании dApp

• Отсутствие Multicall3 — фронтенд делает 10–20 отдельных запросов, увеличивая время загрузки в 3–5 раз.
• Слабые Events — без деталей о переводах балансов сложно строить аналитику.
• Игнорирование UX транзакций — пользователь не видит промежуточных состояний и нажимает кнопку повторно, вызывая дублирующие транзакции.
• Выбор неподходящего indexer'а — The Graph быстр для миллионов событий, но для кастомной агрегации лучше self-hosted.

Опыт нашей команды — 5+ лет в Web3, 10+ реализованных проектов (DeFi, NFT, гейминг). Гарантируем чистоту кода и следование лучшим практикам. Получите консультацию по архитектуре вашего dApp — пишите на почту или в Telegram. Свяжитесь с нами для обсуждения вашего проекта — мы подготовим архитектурную документацию за 2 дня.

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

Половина 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

«Большинство ошибок при выборе сети связаны с игнорированием 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.

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

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

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

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