Разработка на TON: архитектура и реализация
Мы создаём TON-приложения под ключ. Команда с 5+ лет опыта в блокчейне и 20+ завершённых проектов на TON покрывает полный цикл: от проектирования до деплоя и мониторинга. Оценим ваш проект за 1-2 дня — просто напишите нам.
TON — не просто блокчейн с быстрыми транзакциями. Архитектура с бесконечным шардингом и actor model накладывает жёсткие ограничения на проектирование смарт-контрактов и back-end. Если перенести подходы из EVM, на mainnet возникнут проблемы с параллельными запросами и bounce-сообщениями. Например, в одном проекте мы столкнулись с задачей реализации DEX с атомарным обменом — из-за асинхронной модели пришлось перейти на escrow-контракты, что сэкономило месяцы разработки.
Как архитектура TON влияет на разработку приложений?
В TON каждый смарт-контракт — это actor. Последовательная обработка сообщений внутри контракта, параллельная между разными. Нет глобального состояния, нет синхронных вызовов. Вместо этого — сообщения с задержкой на 1-2 блока. Это означает, что атомарность сложных операций требует паттерна commit-confirm-rollback:
- Контракт A фиксирует предварительное состояние и отправляет запрос контракту B.
- B обрабатывает запрос и отправляет confirm или reject.
- 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.
| Критерий |
Tact |
FunC |
| Безопасность |
Высокая (типизация) |
Средняя (низкий уровень) |
| Скорость разработки |
Высокая |
Низкая |
| Оптимизация газа |
Хорошая |
Максимальная |
| Подходит для |
Jetton, NFT, бизнес-логика |
Высоконагруженные контракты |
Стандартные шаблоны (Jetton Minter + Wallet) используем аудированные от TON Foundation. Это снижает затраты на аудит на 70%.
Почему стоит хранить данные в дочерних контрактах?
TON взимает storage fee за хранение данных. Если контракт накапливает все данные пользователей в одном месте, он быстро исчерпает баланс и заморозится. Правильный паттерн: мастер-контракт + per-user контракты (как jetton minter + jetton wallet). Это снижает storage fee в десятки раз по сравнению с монолитным контрактом, экономя до $5 000 в месяц для высоконагруженного DApp.
Как интегрировать TON Connect?
TON Connect 2.0 — протокол подключения кошельков (Tonkeeper, MyTonWallet, Tonhub). Интеграция через @tonconnect/sdk или @tonconnect/ui-react. Пошаговый процесс:
- Установите пакет:
npm install @tonconnect/sdk.
- Создайте экземпляр
TonConnect с настройками приложения.
- Вызовите
connector.connect() для отображения QR-кода.
- Обработайте событие
onStatusChange для получения адреса кошелька.
- Используйте
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 и мониторинг
- Документация и передача исходников
- Поддержка после запуска (опционально)
Процесс разработки
| Этап |
Срок |
| Проектирование |
3-5 дней |
| Разработка контрактов |
1-2 недели |
| Back-end |
1-2 недели |
| Front-end + TON Connect |
1-2 недели |
| Деплой и мониторинг |
2-3 дня |
Итоговые сроки полноценного TON-приложения: 2-4 недели в зависимости от сложности. Закажите разработку — мы рассчитаем точные сроки и стоимость за 1-2 дня.
Типичные ошибки
- Игнорировать bounce. Обрабатывайте bounced message в каждом контракте, отправляющем средства.
- Хранить всё в одном контракте. Используйте per-user контракты.
- Не учитывать storage fees. Закладывайте механизм пополнения.
У нас есть готовые решения и шаблоны для ускорения разработки. Получите консультацию — мы ответим на все вопросы.
Разработка смарт-контрактов
Мы столкнулись с ситуацией: контракт задеплоен, через две недели приходит сообщение — пул дренирован на $800k. Смотрим транзакцию в Tenderly: атакующий вызвал deposit(), внутри callback на ERC-777 повторно вызвал withdraw() — баланс обновился только после второго выхода. Классическая reentrancy, но не через ETH transfer, а через хук ERC-777. ReentrancyGuard стоял только на withdraw().
Такие случаи — не редкость. Смарт-контракт — это финансовая логика без возможности пропатчить её ночью. Наша команда разрабатывает контракты под ключ, встраивая защиту от reentrancy, MEV и gas-атак на ранних этапах.
Как мы разрабатываем смарт-контракты под ключ
Начинаем с аудита бизнес-логики и выбора стека. Solidity 0.8.x — стандарт для EVM-совместимых чейнов: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. Для Solana используем Rust и Anchor: модель аккаунтов и программ требует явного объявления всех ресурсов. Для проектов с формальной верификацией подходит Move (Aptos, Sui) — линейные типы языка исключают копирование ресурсов на уровне компилятора. Vyper выбираем для контрактов, где критична простота аудита (Curve Finance).
| Язык |
Модель исполнения |
Типичная область |
Риски |
| Solidity 0.8.x |
EVM, последовательное исполнение |
DeFi, NFT, токены |
Reentrancy, переполнение (unchecked) |
| Rust (Anchor) |
Solana, параллельное |
Высоконагруженные DEX, игры |
Неправильное объявление аккаунтов |
| Move |
Aptos/Sui, ресурсная |
Крупные протоколы |
Сложность экосистемы |
| Vyper |
EVM, ограниченный синтаксис |
Критические контракты (Curve) |
Зависимость от стабильности компилятора |
Gas optimization — не преждевременная оптимизация, а архитектурное решение. На Ethereum mainnet деплой плохо спроектированного контракта может стоить 2–5 ETH только из-за неоптимального storage layout. Переупаковка структуры Proposal с 7 слотов до 4 сэкономила 18k gas на каждом голосовании — около $1.5 при gas price 30 gwei. Экономия на масштабе протокола с тысячами голосований в день даёт ощутимую годовую выгоду.
Типичные ошибки в gas: передача массивов через memory вместо calldata в external функциях (дороже в 2–3 раза); использование require с длинными строками вместо custom error error InsufficientBalance(...). Кастомные ошибки дешевле на 50–200 gas на revert и передают структурированные данные фронтенду.
Почему аудит смарт-контрактов критичен для безопасности
Аудит — не разовая проверка, а встроенный этап разработки. Используем три уровня:
-
Статический анализ —
Slither (30 секунд в CI) выявляет reentrancy, неинициализированные переменные, опасный delegatecall.
-
Фаззинг и invariant тесты —
Foundry с --fuzz-runs 50000 находит edge cases, которые пропускают сотни unit-тестов. Реальный кейс: AMM контракт с кастомной математикой после 150 тестов в Hardhat — Foundry нашёл integer division truncation, позволявший пылевой атаке копить dust на контракте. Echidna проверяет инварианты («сумма всех балансов ≤ totalSupply»).
-
Ручной code review — наши инженеры с опытом 10+ лет в блокчейне выявляют логические ошибки, которые не ловят инструменты. Для протоколов с TVL > $1M обязателен внешний аудит со стороны Trail of Bits, Consensys Diligence или OpenZeppelin. Срок — 2–4 недели.
Любой апгрейдируемый протокол должен иметь timelock. TimelockController из OpenZeppelin: операция предлагается → ждёт минимальный delay (48–72 часа) → выполняется. Без timelock один скомпрометированный deployer wallet = потеря всего пула.
Какие паттерны апгрейда выбираем
| Паттерн |
Механизм |
Риск |
Когда использовать |
Наш опыт |
| Transparent Proxy (OZ) |
admin vs user разделение |
Storage collision, centralization |
Стандартные проекты |
15+ реализаций |
| UUPS |
Логика апгрейда в implementation |
Забыть _authorizeUpgrade → контракт навсегда сломан |
Газ-оптимизированные проекты |
7 проектов |
| Diamond (EIP-2535) |
Множество facets |
Сложность аудита |
Крупные протоколы с 10+ контрактами |
3 внедрения |
| Beacon Proxy |
Один beacon для множества proxies |
Beacon = single point of failure |
Фабрики однотипных контрактов |
5 фабрик |
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) меняют картину, но пока не массово.
Процесс разработки
-
Аналитика — спецификация функций, диаграмма вызовов, анализ edge cases. Без этого кодинг начинается впустую.
-
Разработка — Solidity/Rust с тестами параллельно. Тест → код → рефакторинг. Используем Foundry для fuzz и invariant тестов.
-
Внутренний аудит — Slither + Echidna + ручной code review. Foundry invariant tests для протокольных инвариантов.
-
Внешний аудит — для проектов с реальными деньгами. Срок: 2–4 недели.
-
Деплой — Foundry scripts или Hardhat Ignition с verify на Etherscan. Gnosis Safe для ownership transfer сразу после деплоя.
-
Мониторинг — 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 недель и идёт параллельно с финальным тестированием где возможно. Стоимость рассчитывается индивидуально — свяжитесь с нами, и мы оценим ваш проект бесплатно.
Закажите разработку смарт-контракта — получите консультацию по архитектуре и защите от reentrancy, MEV и gas-атак. Хотите обсудить детали? Напишите нам — мы подберём оптимальный стек под вашу задачу.