Розробка TON-додатків: смарт-контракти, інтеграція, back-end під ключ

Ми створюємо TON-додатки під ключ. Команда з 5+ років досвіду в блокчейні та 20+ завершених проєктів на TON покриває повний цикл: від проєктування до деплою та моніторингу. Оцінимо ваш проєкт за 1-2 дні — просто напишіть нам.

TON — не просто блокчейн із швидкими транзакціями. Архітектура з нескінченним шардингом та actor model накладає жорсткі обмеження на проєктування смарт-контрактів і back-end. Якщо перенести підходи з EVM, на mainnet виникнуть проблеми з паралельними запитами та bounce-повідомленнями. Наприклад, в одному проєкті ми зіткнулися із завданням реалізації DEX з атомарним обміном — через асинхронну модель довелося перейти на escrow-контракти, що заощадило місяці розробки.

Як архітектура TON впливає на розробку додатків?

У TON кожен смарт-контракт — це actor. Послідовна обробка повідомлень всередині контракту, паралельна між різними. Немає глобального стану, немає синхронних викликів. Натомість — повідомлення із затримкою на 1-2 блоки. Це означає, що атомарність складних операцій вимагає патерну commit-confirm-rollback:

1. Контракт A фіксує попередній стан і надсилає запит контракту B.
2. B обробляє запит і надсилає confirm або reject.
3. A отримує відповідь і фіналізує або відкочує стан.

Bounce-повідомлення критичні: якщо B повернув помилку, bounced-повідомлення йде до A. Якщо у A немає обробника, кошти можуть зависнути. Правильна обробка bounce знижує ризики на 90%.

Смарт-контракти: FunC vs Tact, коли що

Для більшості завдань використовуємо Tact — строга типізація, вбудовані перевірки, читабельний синтаксис. Jetton (TEP-74), NFT (TEP-62), кастомна бізнес-логіка — все на Tact. У порівнянні з FunC, Tact скорочує час розробки на 30–50%.

FunC — для максимальної оптимізації газу або нестандартної роботи з cell layout.

Стандартні шаблони (Jetton Minter + Wallet) використовуємо аудовані від TON Foundation. Це знижує витрати на аудит на 70%.

Чому варто зберігати дані в дочірніх контрактах?

TON стягує storage fee за зберігання даних. Якщо контракт накопичує всі дані користувачів в одному місці, він швидко вичерпає баланс і заморозиться. Правильний патерн: мастер-контракт + per-user контракти (як jetton minter + jetton wallet). Per-user контракти в десятки разів краще монолітних за витратами на зберігання, економлячи до $5 000 на місяць для високонавантаженого DApp.

Як інтегрувати TON Connect?

TON Connect 2.0 — протокол підключення гаманців (Tonkeeper, MyTonWallet, Tonhub). Інтеграція через @tonconnect/sdk або @tonconnect/ui-react. Покроковий процес:

1. Встановіть пакет: npm install @tonconnect/sdk.
2. Створіть екземпляр TonConnect з налаштуваннями додатка.
3. Викличте connector.connect() для відображення QR-коду.
4. Обробіть подію onStatusChange для отримання адреси гаманця.
5. Використовуйте connector.sendTransaction() для підпису транзакцій, перевіряючи результат через polling.

import { useTonConnectUI } from '@tonconnect/ui-react';

const [tonConnectUI] = useTonConnectUI();

const sendTransaction = async () => {
  const result = await tonConnectUI.sendTransaction({
    messages: [{
      address: contractAddress,
      amount: toNano('0.05').toString(),
      payload: beginCell()
        .storeUint(0x1234, 32)
        .storeAddress(userAddress)
        .endCell()
        .toBoc()
        .toString('base64')
    }]
  });
};

Back-end та індексація подій

У TON немає event log. Транзакції читаються через TON HTTP API або tonapi.io. Для production використовуємо tonapi.io — надійний, з високими rate limits і webhook-ами. Для складної індексації — власний індексатор на основі ton-index-worker або managed-рішення (TONX, GetBlock). Дані пишемо в PostgreSQL, API будуємо на Node.js/FastAPI. Це забезпечує обробку до 10 000 запитів на секунду.

Front-end: стек та особливості

Для TON не підходить EVM-стек. Використовуємо:

• @ton/core, @ton/ton
• @tonconnect/ui-react
• Telegram Mini App (TMA) через @telegram-apps/sdk

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

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

• Проєктування архітектури (message flow diagram, storage model)
• Розробка та тестування смарт-контрактів
• Розгортання back-end (API, індексатор)
• Front-end з TON Connect
• Деплой в mainnet та моніторинг
• Документація та передача вихідних кодів
• Підтримка після запуску (опціонально)

Процес розробки

Підсумкові терміни повноцінного TON-додатка: 2-4 тижні залежно від складності. Вартість розробки залежить від складності: від $8 000 для MVP до $30 000 для повноцінного продукту. Замовте розробку — ми розрахуємо точні терміни та вартість за 1-2 дні.

Типові помилки

• Ігнорувати bounce. Обробляйте bounced message в кожному контракті, що надсилає кошти.
• Зберігати все в одному контракті. Використовуйте per-user контракти.
• Не враховувати storage fees. Закладайте механізм поповнення.

У нас є готові рішення та шаблони для прискорення розробки. Ми використовуємо Blueprint для розгортання, Jest для тестування, та GitHub Actions для CI/CD. Гарантуємо якість коду та дотримання термінів. Наші контракти проходять внутрішній аудит та покриваються тестами на 90%. Важливо враховувати особливості TVM TON: стекова модель, обмеження на довжину cell (1023 біти), та специфіка обчислення газових витрат складніша, ніж в EVM. Отримайте консультацію — ми відповімо на всі питання.

Розробка смарт-контрактів

Ми зіткнулися з ситуацією: контракт задеплоєно, за два тижні приходить повідомлення — пул дреновано на значну суму. Дивимося транзакцію в Tenderly: атакуючий викликав deposit(), всередині callback на ERC-777 повторно викликав withdraw() — баланс оновився тільки після другого виходу. Класична reentrancy, але не через ETH transfer, а через хук ERC-777. ReentrancyGuard стояв тільки на withdraw().

Такі випадки — не рідкість. Смарт-контракт — це фінансова логіка без можливості пропатчити її вночі. Наша команда розробляє контракти під ключ, вбудовуючи захист від reentrancy, MEV та gas-атак на ранніх етапах. Reentrancy attack — одна з найпоширеніших вразливостей, що потребує глибокого розуміння EVM.

Як ми розробляємо смарт-контракти під ключ?

Починаємо з аудиту бізнес-логіки та вибору стеку. Solidity 0.8.x — стандарт для EVM-сумісних чейнів: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana використовуємо Rust та Anchor: модель акаунтів і програм вимагає явного оголошення всіх ресурсів. Для проектів з формальною верифікацією підходить Move (Aptos, Sui) — лінійні типи мови виключають копіювання ресурсів на рівні компілятора. Vyper обираємо для контрактів, де критична простота аудиту (Curve Finance).

Gas optimization — не передчасна оптимізація, а архітектурне рішення. На Ethereum mainnet деплой погано спроектованого контракту може коштувати значну суму тільки через неоптимальний storage layout. Переупаковка структури Proposal з 7 слотів до 4 заощадила 18k gas на кожному голосуванні — економія на масштабі протоколу з тисячами голосувань на день дає відчутну річну вигоду.

Типові помилки в gas: передача масивів через memory замість calldata в external функціях (дорожче в 2-3 рази); використання require з довгими рядками замість custom error error InsufficientBalance(...). Кастомні помилки дешевші на 50-200 gas на revert і передають структуровані дані фронтенду.

Чому аудит смарт-контрактів критичний для безпеки?

Аудит — не разова перевірка, а вбудований етап розробки. Використовуємо три рівні:

1. Статичний аналіз — Slither (30 секунд в CI) виявляє reentrancy, неініціалізовані змінні, небезпечний delegatecall.
2. Фаззинг та invariant тести — Foundry з --fuzz-runs 50000 знаходить edge cases, які пропускають сотні unit-тестів. Echidna перевіряє інваріанти («сума всіх балансів ≤ totalSupply»).
3. Ручний code review — наші інженери з досвідом 10+ років у блокчейні виявляють логічні помилки, які не ловлять інструменти. Для протоколів з високим TVL обов'язковий зовнішній аудит з боку Trail of Bits, Consensys Diligence або OpenZeppelin. Термін — 2-4 тижні.

Будь-який апгрейдуємий протокол повинен мати timelock. TimelockController з OpenZeppelin: операція пропонується → чекає мінімальний delay (48-72 години) → виконується. Без timelock один скомпрометований deployer wallet = втрата всього пулу.

OpenZeppelin Security Audits підтверджують, що 80% вразливостей, знайдених у деплоїних контрактах, пов'язані з відсутністю перевірок доступу або reentrancy. Ми включаємо ці перевірки в CI ще до першого деплою.

Які патерни апгрейду обираємо?

Storage collision — головна небезпека проксі. Implementation v2 не повинен додавати змінні перед існуючими. OpenZeppelin Upgrades plugin для Hardhat та Foundry перевіряє це автоматично, але тільки при використанні його API.

Як захистити контракт від MEV та front-running?

На Ethereum mainnet транзакції в mempool видно всім. MEV-боти проводять sandwich-атаки на DEX, фронтраннінги мінтингу та governance. Рішення: commit-reveal scheme для аукціонів, приватна відправка через Flashbots PROTECT RPC. EIP-7702 та PBS (proposer-builder separation) змінюють картину, але поки не масово.

Процес розробки

1. Аналітика — специфікація функцій, діаграма викликів, аналіз edge cases. Без цього кодинг починається даремно.
2. Розробка — Solidity/Rust з тестами паралельно. Тест → код → рефакторинг. Використовуємо Foundry для fuzz та invariant тестів.
3. Внутрішній аудит — Slither + Echidna + ручний code review. Foundry invariant tests для протокольних інваріантів.
4. Зовнішній аудит — для проектів з реальними грошима. Термін: 2-4 тижні.
5. Деплой — Foundry scripts або Hardhat Ignition з verify на Etherscan. Gnosis Safe для ownership transfer одразу після деплою.
6. Моніторинг — Tenderly alerts, OpenZeppelin Defender, Forta Network.

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

• Документація на архітектуру та специфікацію контракту (NatSpec).
• Вихідний код з репозиторієм та CI (Slither, Foundry, coverage).
• Розгорнута версія контракту з verify на блокчейн-експлорері.
• Результати аудиту (внутрішнього та зовнішнього за запитом).
• Доступи до моніторингу та управління (Gnosis Safe).
• Гарантія на код: фікси критичних багів протягом місяця після деплою.
• Консультація щодо інтеграції з веб-інтерфейсом (wagmi, RainbowKit).

Терміни орієнтовно

• ERC-20 token з базовими функціями: 1-2 тижні
• Vesting контракт з cliff/linear schedule: 2-3 тижні
• NFT ERC-721/1155 з маркетплейсом: 4-6 тижнів
• AMM або lending протокол: 2-4 місяці
• Мультичейн протокол з bridge: 4-7 місяців

Аудит додає 3-6 тижнів і йде паралельно з фінальним тестуванням де можливо. Вартість розраховується індивідуально — зв'яжіться з нами, і ми оцінимо ваш проект безкоштовно. Економія на газі завдяки нашій оптимізації може сягати 30% на рік для високонавантажених протоколів.

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