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

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

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

Проектування безпечної архітектури dApp

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

Чому 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 подій на секунду — в 10 разів швидше ніж self-hosted indexer. Для одного з клієнтів ми налаштували індекс, який за 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" },
  ],
});

Підключення гаманця

Налаштовуємо 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 — газ робить продукт нерентабельним (один swap може коштувати $50, на Polygon — $0.02). Зробили governance токен без моделі захоплення вартості — ціна колапсує через 6 місяців після TGE. Або вибрали Solana заради throughput, не врахувавши, що команда пише на Solidity, а не на Rust — learning curve 3–6 місяців. На одному проекті з обсягом контрактів 2000 рядків Solidity ми заощадили клієнту $40 000 на переробках, вчасно перевівши його на Arbitrum.

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

Як вибрати блокчейн для Web3-продукту?

Вирішальний фактор — транзакційна модель продукту. Якщо денне навантаження менше 100 транзакцій — вам підійде Ethereum mainnet, але ви переплачуєте за security. Розгляньте Polygon PoS (вартість транзакції дуже низька, finality 2–3 секунди, EVM-сумісність 100%). Якщо навантаження 1 000–100 000 транзакцій на день, користувачі чутливі до газу — Arbitrum One або Optimism. Обидва EVM-сумісні, вартість транзакції низька. Arbitrum використовує Nitro (WASM-based fraud proofs), Optimism — Bedrock з OP Stack. Withdrawal window: 7 днів для обох (optimistic rollup finality). Для проектів з instant finality — Arbitrum Nova (AnyTrust, дешевше, менше decentralization) або ZK rollups. Якщо порівняти: Arbitrum One дешевший за Ethereum mainnet у 100 разів за середньої комісії — це критично для DeFi з високою частотою транзакцій.

Якщо потрібен 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). Неправильний вибір мережі може коштувати значних переробок та втрати ринкового вікна — ми це бачимо на кожному другому due diligence.

«Більшість помилок при виборі мережі пов'язані з ігноруванням 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 високому, команда має 20%, і перший unlock через 6 місяців — на ринок за 2 роки виходить значна кількість токенів. Ринок дисконтує це з першого дня. Більш здорова структура: 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. На практиці Foundry дає приріст швидкості тестування у 5 разів порівняно з Hardhat — це означає години замість днів на регресію.

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 секунду. Переробка обійшлася у $25 000 та два тижні затримки. Якби discovery врахувала вимоги до finality, цих витрат вдалося б уникнути.

Що входить в роботу

Орієнтири по термінах та вартості

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

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