FunC-контракты для TON: разработка, аудит, деплой под ключ

Смарт-контракты на FunC для TON: от идеи до mainnet

Мы специализируемся на создании смарт-контрактов для TON. TON — это не ещё один EVM-клон. Разработчик, который приходит с опытом Solidity, первые две недели проводит в состоянии лёгкого шока: стек-ориентированная виртуальная машина TVM, ячеистая модель хранения данных через Cell, асинхронная передача сообщений между контрактами, и FunC — язык, который выглядит как функциональный C с элементами Lisp. Это не недостатки, это архитектурные решения, которые дают TON уникальные свойства масштабируемости. Но кривая обучения резкая. За 5 лет мы реализовали более 120 контрактов на TON и знаем, как пройти этот путь без потерь. Средний gas-расход наших контрактов на 25% ниже, чем у референсных имплементаций — результат многолетней оптимизации.

Согласно документации TON Foundation, Jetton — стандарт для токенов в сети TON.

Как работают асинхронные сообщения в TON?

В Solidity contractA.functionB() — это синхронный вызов в рамках одной транзакции. В TON всё иначе: контракты общаются через сообщения, каждое из которых обрабатывается в отдельной транзакции. Если контракт A отправляет сообщение контракту B, который отправляет сообщение контракту C — это три отдельные транзакции в трёх отдельных блоках. Это ломает привычные паттерны и требует явной машины состояний в storage.

TVM и Cell — не то, к чему вы привыкли

В EVM контракт — это байткод, storage — key-value хранилище с 32-байтными слотами. В TVM контракт хранится как дерево Cell-объектов. Каждая Cell — до 1023 бит данных и до 4 ссылок на другие Cell. Storage контракта — тоже Cell-дерево, которое целиком загружается при каждом вызове и целиком сохраняется обратно. Это влечёт конкретные следствия: нет слот-коллизий как в EVM proxy, но чтение глубоко вложенной структуры требует последовательного разбора Cell через begin_parse() / load_uint() / load_ref(). Забудешь порядок полей при десериализации — получишь неверные данные без ошибки компилятора.

Почему обработка bounce-сообщений критична для безопасности?

Bounce-сообщение — это аналог возврата средств в случае ошибки. Если контракт-получатель реверснулся, TON автоматически отправляет bounce-сообщение отправителю с оставшимися деньгами. Если отправитель не обработал bounce — средства зависают навечно. Мы видели проекты, потерявшие десятки тысяч TON из-за отсутствия bounce-хендлера. На этапе проектирования мы обязательно закладываем state machine и timeout-механизмы.

Gas-модель в TON

В TON нет привычного gas limit на транзакцию. Есть storage fees — контракт платит за хранение своего состояния каждую секунду. Контракт с большим storage и нулевым балансом в какой-то момент будет заморожен. Это нужно учитывать при проектировании: контракты-хранилища данных (например, индивидуальные jetton-кошельки) должны иметь механизм пополнения или минимальный баланс. Оптимизация storage — одна из наших ключевых компетенций.

Как избежать потери средств при bounce: пошаговая инструкция

1. Реализуйте отдельную bounce-функцию по op-code.
2. Все bounce-хендлеры явно документируйте в коде.
3. Используйте state machine в storage с статусами pending, processing, completed, failed.
4. Добавьте timeout: если операция в статусе processing более N секунд — автоматический rollback.
5. Для каждого bounce предусмотрите отдельный хендлер.

Пропустить обработку bounce — типичная ошибка новичков. Контракт отправляет TON другому контракту, тот реверсируется, coins возвращаются как bounce-сообщение. Если отправитель не обработал bounce — coins уходят в никуда.

Сравнение TON и EVM для задач разработки

Таблица показывает, что TON не «лучше» или «хуже» — он другой. Для задач с высоким TPS и дешёвыми транзакциями (payments, gamefi, miniapps в Telegram) — архитектура TON оптимальна. TON в 10 раз быстрее Ethereum по пропускной способности.

Как мы пишем контракты на FunC

Стек разработки

Blueprint — стандартный инструмент для разработки и тестирования TON-контрактов. Предоставляет окружение для локального запуска TVM, написания тестов на TypeScript, деплоя через кастомизируемые скрипты. toncli используем для быстрого прототипирования. Для новых проектов выбираем Blueprint. Tact — высокоуровневый язык над FunC, снижающий порог входа; используем для проектов, где скорость важнее максимального контроля над байткодом. TEP-74 — стандарт Jetton, который мы кладём в основу токенов.

Официальные стандарты: TEP-74 (Jetton), TEP-62 (NFT), TEP-64 (метаданные). OpenZeppelin-аналога в TON нет — есть референсные имплементации от TON Foundation, которые мы берём за базу.

Типичная ошибка при работе с Jetton

Jetton-архитектура шардированная: у каждого пользователя — отдельный контракт-кошелёк. Transfer — два сообщения от кошелька-отправителя к кошельку-получателя. Стандартная ошибка: контракт-получатель не реализует обработчик transfer_notification — jetton приходят, но контракт не меняет состояние.

Процесс разработки TON-контракта

• Проектирование message flow (3-5 дней). До написания кода — полная диаграмма сообщений: op-code, направление, bounce-сценарии.
• Разработка на FunC + тесты на TypeScript (1-3 недели). Blueprint-тесты покрывают happy path и все bounce-сценарии (80%+ покрытия).
• Ревью storage layout. Проверяем порядок сериализации/десериализации Cell, корректность bounce.
• Деплой на testnet → mainnet. Верификация кода через TON Verifier.

Оценка сложности и сроков

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

• Исходный код на FunC/Blueprint с комментариями
• Тесты на TypeScript (покрытие 80%+)
• Документация по message flow и хендлерам
• Инструкция по деплою (testnet + mainnet)
• Поддержка при развёртывании и первичном запуске
• Аудит контрактов (опционально)

Свяжитесь с нами для оценки вашего проекта. Получите консультацию по архитектуре вашего контракта бесплатно. Закажите разработку сегодня — мы подготовим предложение под вашу архитектуру.

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

Мы столкнулись с ситуацией: контракт задеплоен, через две недели приходит сообщение — пул дренирован на $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).

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 и передают структурированные данные фронтенду.

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

Аудит — не разовая проверка, а встроенный этап разработки. Используем три уровня:

1. Статический анализ — Slither (30 секунд в CI) выявляет reentrancy, неинициализированные переменные, опасный delegatecall.
2. Фаззинг и invariant тесты — Foundry с --fuzz-runs 50000 находит edge cases, которые пропускают сотни unit-тестов. Реальный кейс: AMM контракт с кастомной математикой после 150 тестов в Hardhat — Foundry нашёл integer division truncation, позволявший пылевой атаке копить dust на контракте. Echidna проверяет инварианты («сумма всех балансов ≤ totalSupply»).
3. Ручной code review — наши инженеры с опытом 10+ лет в блокчейне выявляют логические ошибки, которые не ловят инструменты. Для протоколов с TVL > $1M обязателен внешний аудит со стороны Trail of Bits, Consensys Diligence или OpenZeppelin. Срок — 2–4 недели.

Любой апгрейдируемый протокол должен иметь timelock. TimelockController из OpenZeppelin: операция предлагается → ждёт минимальный delay (48–72 часа) → выполняется. Без timelock один скомпрометированный deployer wallet = потеря всего пула.

Какие паттерны апгрейда выбираем

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 недель и идёт параллельно с финальным тестированием где возможно. Стоимость рассчитывается индивидуально — свяжитесь с нами, и мы оценим ваш проект бесплатно.

Закажите разработку смарт-контракта — получите консультацию по архитектуре и защите от reentrancy, MEV и gas-атак. Хотите обсудить детали? Напишите нам — мы подберём оптимальный стек под вашу задачу.