Розробка смарт-контрактів та DApps: аудит, деплой, супровід

Розробка децентралізованих додатків: смарт-контракти, аудит, деплой

Ми часто стикаємося з ситуацією, коли клієнт приходить з ідеєю "запустити блокчейн-проєкт", але не може чітко сформулювати, навіщо йому блокчейн. Головне питання: що саме блокчейн вирішує у вашому продукті, чого не вирішує традиційна база даних? Якщо відповідь розмита — швидше за все, вам потрібна просто розподілена система, а не блокчейн. Якщо відповідь чітка — trustless виконання логіки, верифікованість даних, токенізація активів, permissionless участь — ми починаємо проєктувати. Наша команда має 10+ років досвіду в блокчейн-розробці та реалізувала понад 50 проєктів — від NFT-маркетплейсів до DeFi-протоколів з TVL понад $10M. Ми пропонуємо повний цикл розробки під ключ: від архітектури до деплою та аудиту. Оцінка бюджету — перший крок у будь-якому проєкті, і ми завжди її проводимо на початковій консультації.

Як вибрати блокчейн для вашого проєкту?

Не існує "найкращого блокчейну" — є правильний для конкретного use case.

EVM-сумісні мережі

Ethereum mainnet — максимальна decentralization та security, development tooling першого рівня (Foundry, Hardhat, Slither, Echidna). Виправданий для: протоколів з великими TVL, де безпека > вартості; фінансових примітивів, які повинні бути composable з DeFi екосистемою.

Arbitrum / Optimism — Optimistic Rollups. EVM-еквівалентність (Arbitrum One) або EVM-сумісність (OP Stack). Gas в 10–50x дешевший за mainnet, finality ~7 днів для withdrawals (fraud proof window). Виправданий для додатків з високою частотою транзакцій: trading, gaming, соціальні додатки.

Base — OP Stack L2 від Coinbase. Швидко зростаюча екосистема, хороший onramp через Coinbase. Підходить для consumer-facing додатків.

Polygon PoS — не L2, а sidechain з мостом до Ethereum. Швидко, дешево, але інша модель безпеки. Хороший для NFT-проєктів з частими транзакціями.

zkSync Era / Polygon zkEVM / Scroll — ZK Rollups. Більш строгі гарантії безпеки ніж Optimistic (немає fraud window), але ZK proofs створюють overhead на execution. zkSync має Native Account Abstraction (AA) на рівні протоколу — це important архітектурна перевага для UX.

Не-EVM

Solana — high throughput (65k TPS теоретично, ~3–5k TPS реально), паралельне виконання транзакцій через Sealevel, низькі комісії. Програмування на Rust через Anchor framework. Tooling значно менш зрілий ніж EVM, debugger примітивний, помилки гірше читаються. Виправданий для: high-frequency trading, gaming з real-time механіками, додатків де gas cost критичний.

TON — нативна інтеграція з Telegram (900M MAU). FunC/Tact для смарт-контрактів. Якщо ваша аудиторія в Telegram — серйозний аргумент на користь TON.

Cosmos SDK — для випадків, коли потрібен власний blockchain (application-specific chain). IBC для міжмережевої взаємодії. Високий поріг входу, але повний контроль над консенсусом, governance, gas token.

Які вразливості смарт-контрактів зустрічаються найчастіше?

За роки роботи з аудитами, ось що зустрічається найчастіше:

Reentrancy — класика. Досі зустрічається. Захист: ReentrancyGuard від OpenZeppelin + CEI патерн (Checks-Effects-Interactions):

// НЕПРАВИЛЬНО:
function withdraw(uint256 amount) external {
    token.transfer(msg.sender, amount); // interaction до effect
    balances[msg.sender] -= amount;     // effect після
}

// ПРАВИЛЬНО:
function withdraw(uint256 amount) external nonReentrant {
    balances[msg.sender] -= amount;     // effect
    token.transfer(msg.sender, amount); // interaction
}

Price manipulation через flash loans — якщо контракт читає ціну з Uniswap spot price. Рішення: TWAP (Time-Weighted Average Price) через IUniswapV3Pool.observe() або Chainlink Price Feed.

Integer overflow/underflow — в Solidity 0.8.x вбудований захист, але при unchecked блоках та при кастомній математиці з downcast — все ще актуально.

Signature replay — при використанні ecrecover без nonce або chain ID в підписаному повідомленні. EIP-712 + EIP-2612 (Permit) вирішують це стандартним способом.

Front-running — MEV. Для AMM-подібних контрактів: deadline + slippage tolerance. Для сенситивних операцій: commit-reveal схема.

Які інструменти ми використовуємо?

Foundry — найкращий інструмент для серйозної розробки. Тести на Solidity, fuzz testing з коробки, форки mainnet в один флаг:

forge test --fork-url $ETH_RPC --fork-block-number 19000000 -vvv

Fuzz тестування знаходить edge cases, які ручні тести пропускають:

function testFuzz_deposit(uint256 amount) public {
    amount = bound(amount, 1, type(uint128).max); // розумні межі
    deal(address(token), user, amount);
    vm.prank(user);
    vault.deposit(amount, user);
    assertEq(vault.totalAssets(), amount);
}

Slither — статичний аналізатор. Запускаємо в CI на кожен PR, критичні знахідки блокують мерж.

Echidna — property-based fuzzer. Для інваріантів: "totalSupply завжди дорівнює сумі всіх балансів", "здоров'я протоколу ніколи не йде в мінус".

OpenZeppelin Security Audits рекомендують комбінувати кілька інструментів для покриття різних типів вразливостей.

Як виглядає типовий стек для деплою?

Жодних деплоїв з EOA в production. Схема:

Developer EOA → Gnosis Safe 3/5 multisig → Timelock (48h delay) → Contract

Timelock дає користувачам час зреагувати на шкідливий апгрейд. Для DeFi протоколів з TVL > $1M — обов'язковий.

Hardhat Ignition або Foundry Deploy Scripts для відтворюваних деплоїв. Всі параметри деплою — в version control, не в головах розробників.

Аудит — не фінальний крок, а частина процесу. Для серйозних протоколів: внутрішній review (Slither + Echidna + ручний аналіз) → попередній аудит від однієї фірми → основний аудит → виправлення знахідок → повторний аудит змін. Терміни: 4–8 тижнів для типового DeFi протоколу середньої складності. Бюджет розраховується індивідуально.

Як ми розробляємо: покроково

1. Аналіз вимог та вибір мережі. Визначаємо, який блокчейн найкраще підходить під ваш use case, враховуючи токеноміку, очікуване навантаження та юридичні аспекти.
2. Проєктування архітектури контрактів. Розробляємо діаграми взаємодії, специфікації інтерфейсів та схему даних.
3. Розробка смарт-контрактів. Пишемо код на Solidity або Rust, покриваємо unit-тестами (100% coverage).
4. Інтеграційне тестування. Запускаємо форк mainnet і перевіряємо сценарії повністю.
5. Зовнішній аудит. Передаємо код перевіреній фірмі, виправляємо зауваження, повторний аудит.
6. Деплой в testnet та mainnet. Використовуємо мультисиг-гаманці та часові затримки.
7. Моніторинг та підтримка. Налаштовуємо Tenderly, OpenZeppelin Defender, даємо 30 днів після деплою.

Етапи проєкту

Реалістичний термін від ідеї до mainnet: 3–6 місяців для протоколу середньої складності. Проєкти, які "запускаються за 2 тижні", зазвичай мають незакриті критичні вразливості.

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

• Архітектурна документація з обґрунтуванням вибору мережі та патернів.
• Вихідні коди смарт-контрактів з коментарями та unit-тестами (100% coverage).
• Інтеграційні тести на форку mainnet.
• Звіт зовнішнього аудиту з рекомендаціями.
• Розгортання в testnet та mainnet (при необхідності).
• Інструкції з експлуатації та підтримка протягом 30 днів після деплою.
• Доступ до інструментів моніторингу (Tenderly, OpenZeppelin Defender).

Зв'яжіться з нами для оцінки вашого проєкту. Ми проаналізуємо вимоги, запропонуємо оптимальну блокчейн-архітектуру та розрахуємо терміни. Отримайте консультацію — це допоможе уникнути дорогих помилок на старті.

Розгортання блокчейн-інфраструктури: як уникнути простоїв?

Subgraph впав о 3:47 ночі. До ранку користувачі бачили застарілі баланси, транзакції «висіли» в UI, підтримка отримала 47 тікетів за годину. Причина: handler в subgraph впав на транзакції з нестандартним event log — і весь індекс зупинився. Ми стикалися з такими ситуаціями десятки разів. Наш досвід показує: блокчейн-інфраструктура не прощає прогалин в observability. Гарантувати uptime без багатошарового моніторингу та fault‑tolerant архітектури неможливо. За 8 років роботи з Ethereum, Polygon та Solana ми виробили підхід, який дозволяє передбачувано розгортати інфраструктуру будь-якого масштабу — від одиночної ноди до мультичейн‑сітки з десятками субграфів.

Архітектура RPC-шару

Кожна взаємодія dApp з блокчейном йде через RPC — JSON‑RPC API, яку надає нода. Три варіанти:

Managed providers — Alchemy, QuickNode, Infura, Ankr. Мінімальні операційні витрати, SLA, вбудований моніторинг. Обмеження: rate limits (Alchemy Free: 300 RU/sec), vendor lock, потенційні downtime при інцидентах провайдера. Для більшості проектів — правильний вибір на старті.

Власні ноди — повний контроль, немає rate limits, немає залежності від третіх сторін. Вартість: архівна нода Ethereum займає 2.5–3TB SSD, потребує потужний сервер та DevOps‑підтримку. Sync з нуля на Ethereum через Geth/Nethermind — 3–7 днів. Виправдано при високому навантаженні або вимогах до latency.

Гібрид — власна нода як primary, managed provider як fallback. Стандарт для протоколів з високим TVL. Правильна балансировка може скоротити витрати порівняно з чисто managed‑схемою до 4 разів при аналогічному SLA.

Як налаштувати RPC-шар без єдиної точки відмови?

Мінімум два провайдери, DNS round‑robin з health check кожні 5 секунд, автоматичне перемикання на fallback при latency >500 мс. На практиці це дає 99.99% доступності при будь-якому збої провайдера. Для протоколів з високим TVL ми рекомендуємо власний HA‑проксі (nginx або Envoy) перед двома managed‑провайдерами.

Чому гібридна RPC-схема вигідніша за чисто managed?

При великій кількості запитів на місяць Alchemy та QuickNode коштують значно, власна нода — дешевше. Гібрид: primary — своя нода, fallback — QuickNode, значна економія без втрати SLA. Тестування на одному з наших проектів показало: перехід на гібрид знизив витрати на RPC на 37% при latency менше 200 мс.

Клієнти нод Ethereum

Execution clients: Geth (найбільш використовуваний), Nethermind (C#, швидка sync), Besu (Java, enterprise), Erigon (найшвидший sync, архівний режим ефективний по диску — ~2TB замість 3TB).

Consensus clients (post‑Merge): Lighthouse (Rust), Prysm (Go), Teku (Java), Nimbus (Nim). Кожна нода після The Merge потребує пари execution + consensus client.

Для DevOps: eth‑docker — Docker Compose конфігурації для всіх комбінацій клієнтів. Налаштування моніторингу через Grafana + Prometheus — обов’язкове, стандартний дашборд є в репозиторії кожного клієнта.

The Graph: індексація подій

The Graph Protocol — decentralized indexing. Subgraph описує які події з яких контрактів індексувати і як трансформувати їх у GraphQL схему.

Структура subgraph:

• subgraph.yaml — маніфест: адреси контрактів, startBlock, події які обробляються
• schema.graphql — GraphQL схема entities
• src/mapping.ts — AssemblyScript обробники подій

dataSources:
  - kind: ethereum
    name: UniswapV3Pool
    network: mainnet
    source:
      address: "0x88e6A0c2dDD26FEEb64F039a2c41296FcB3f5640"
      abi: UniswapV3Pool
      startBlock: 12370624
    mapping:
      eventHandlers:
        - event: Swap(indexed address,indexed address,int256,int256,uint160,uint128,int24)
          handler: handleSwap

AssemblyScript handlers — не TypeScript. Немає nullable types, немає closures, немає багатьох стандартних API. Помилка в handler зупиняє індексацію subgraph-а на тій транзакції. Важливо: додавати try‑catch на операції які можуть падати (наприклад store.get() для entity яка може не існувати). Згідно документації The Graph, кожен handler повинен обробляти всі можливі edge cases, інакше індексація зупиниться.

Уникнення зупинки індексації субграфа

Лог файли Graph Node моніторяться в реальному часі, при hasIndexingErrors = true спрацьовує алерт і автоматичний рестарт ноди (через systemd або Kubernetes). Типовий downtime при помилці — 150–300 секунд до відновлення. Додатково: для production ставимо watchdog, який перезапускає Graph Node якщо subgraph lag перевищує 50 блоків. Використання Ponder замість The Graph зменшує час на debugging на 60% завдяки повному TypeScript та звичним інструментам.

Вибір між Hosted Service та Decentralized Network

Graph Hosted Service (безкоштовний, централізований) deprecated на користь Subgraph Studio + Graph Network. Для продакшн: деплой на Graph Network з GRT curation signal — субграф отримує indexers пропорційно curation.

Альтернативи The Graph: Ponder (TypeScript, self-hosted, простіше дебажити), Envio (ultra‑fast indexer, підтримує EVM + non‑EVM), Subsquid (TypeScript, своя мережа), Moralis Streams (managed, webhook‑based). Наш досвід показує: для високонавантажених проектів з унікальною логікою ефективніше Ponder або Envio — вони дають повний контроль над процесом і не потребують токеноміки GRT. Ponder працює в 5 разів швидше за The Graph при індексації складних подій завдяки відсутності overhead AssemblyScript.

Webhooks та real-time нотифікації

Alchemy Webhooks та QuickNode Streams дозволяють отримувати події в реальному часі через HTTP webhook або WebSocket. Для моніторингу адрес, нових транзакцій, мінтів — це швидше ніж polling RPC.

Tenderly — платформа для моніторингу та алертів. Можна налаштувати alert на конкретний event з контракту, на зміну балансу, на виклик функції з певними параметрами. Симуляція транзакцій через Tenderly API — безцінно для debugging.

Моніторинг та observability

Мінімальний стек моніторингу для протоколу:

On‑chain: OpenZeppelin Defender Sentinel — watches contract events, викликає webhook або Autotask при спрацьовуванні умов. Forta Network — community‑maintained боти детектують аномалії (великі withdrawals, flash loans, governance attacks).

Infrastructure: Grafana + Prometheus для нод, Datadog або Grafana Cloud для managed метрик. Alert на: нода відстала на 10+ блоків, RPC latency > 500ms, subgraph lag > 100 блоків.

Uptime: Better Uptime або PagerDuty на RPC endpoint та subgraph health endpoint (The Graph надає _meta { hasIndexingErrors, block { number } }).

Обмеження моніторингу без Tenderly

Tenderly дає симуляцію транзакцій та детальні трейси — це критично для налагодження помилок у субграфах та смарт‑контрактах. Forta ж фокусується на аномаліях у мережі, а не на вашій інфраструктурі. Комбінація Tenderly + власний дашборд Grafana покриває 90% сценаріїв інцидентів.

Мультичейн інфраструктура

Протокол на 5 чейнах = 5 окремих RPC endpoints, 5 subgraphs, 5 моніторинг‑конфігів. Це керовано, але потрібна автоматизація деплою.

Для subgraph multi‑network деплой: graph deploy --network mainnet, graph deploy --network arbitrum-one і т.д. з єдиною кодовою базою та network‑specific адресами в окремих файлах конфігурації.

Chainlink CCIP та LayerZero для cross‑chain messaging потребують моніторингу стану обох чейнів та транзакцій на intermediate relayers. Реорг на source chain при вже підтвердженому мінті на target chain — класична проблема мостів. Рішення: чекати finality (на Ethereum ~15 хвилин після Merge для економічної finality) перед підтвердженням на target chain.

Процес налаштування інфраструктури

1. Аудит поточного стеку — визначаємо чейни, обсяг запитів, вимоги до latency та доступності.
2. Проектування архітектури — вибір провайдерів, балансировка, redundancy.
3. Розробка subgraph — маніфест → схема → handlers → тестування на локальній Graph Node → деплой на testnet → mainnet.
4. Конфігурація моніторингу — Tenderly alerts, Grafana дашборд, PagerDuty інтеграція.
5. Документація та runbook — що робити при: subgraph fell behind, RPC downtime, нода desync.
6. Передача в експлуатацію — навчання команди, передача доступів, підтримка перший місяць.

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

• Розгортання managed або self‑hosted нод Ethereum, Polygon, BNB Chain
• Налаштування RPC‑шару з primary/fallback та load balancing
• Розробка та деплой subgraph під ваш протокол
• Підключення моніторингу (Tenderly, Grafana, алерти)
• Створення runbook та документації з експлуатації
• Навчання команди (до 4 годин онлайн)
• Підтримка протягом 30 днів після здачі

Які терміни виконання?

Всі проекти ведуться в репозиторії на GitHub/GitLab з CI/CD, код конфігурацій залишається у вас. Замовте розгортання інфраструктури — розкажемо, як скоротити витрати без втрати надійності. Отримайте консультацію — покажемо, як ми розгортали інфраструктуру для протоколу з високим TVL на Ethereum та Arbitrum. Зв'яжіться з нами.