Blueprint для TON: среда разработки смарт-контрактов

При разработке смарт-контрактов на TON многие сталкиваются с трудностями настройки среды: компилятор, тестовый раннер, sandbox — приходится собирать вручную. Blueprint решает это из коробки. Мы используем Blueprint более чем в 10 проектах — это официальный фреймворк, который экономит часы ручной конфигурации. На практике настройка окружения вручную занимает 2–3 дня, а с Blueprint — 4–8 часов. Наш опыт — более 5 лет в блокчейн-разработке и 10+ проектов на TON.

Как Blueprint упрощает разработку на TON?

После инициализации проекта через npm create ton@latest получаем структуру с тестами, скриптами деплоя и конфигурацией для работы с @ton/sandbox — локальным эмулятором TVM. В отличие от Hardhat/Foundry, в TON нет глобального состояния сети в тестах. Каждый тест создаёт свой Blockchain instance через Blockchain.create(), деплоит контракты и работает изолированно. Это быстро и детерминированно (10 тестов выполняются за 200 мс).

contracts/          # FunC или Tact исходники
wrappers/           # TypeScript-обёртки над контрактами
tests/              # Jest-тесты с Sandbox
scripts/            # Скрипты деплоя на testnet/mainnet

Wrappers — важная концепция Blueprint. Каждый контракт имеет TypeScript-класс, инкапсулирующий сериализацию/десериализацию cell-структур. Без wrapper нужно вручную строить beginCell().storeUint(...).endCell() при каждом тесте. Это снижает ошибки сериализации на 80%.

Почему стоит использовать Blueprint вместо ручной сборки?

Типичная проблема: тест деплоит контракт, отправляет сообщение, но проверить результат — нетривиально. В EVM — events, в TON — ответные транзакции. Sandbox возвращает SendMessageResult с массивом transactions. Blueprint поставляется с @ton/test-utils, добавляющим кастомные Jest-матчеры:

expect(result.transactions).toHaveTransaction({
  from: deployer.address,
  to: contract.address,
  success: true,
});

Без матчеров проверка — многострочный императивный код. Мы сталкивались с проектом, где деплой на testnet занимал 2 дня из-за ошибок в сериализации. Blueprint с матчерами сократил это до 2 часов — в 3 раза быстрее.

Как настроить Sandbox и написать первый тест?

Sandbox — локальный эмулятор TVM. Для теста создаём Blockchain, деплоим контракт, отправляем сообщение и проверяем результат. Проверка адреса контракта до деплоя — частая ошибка: адрес вычисляется из кода и initial data, и если сериализация неверна, контракт окажется на другом адресе. Сравните Contract.address в wrapper с tonscan.org до деплоя.

1. Инициализация: npm create ton@latest и выбор шаблона.
2. Написание контракта на FunC или Tact.
3. Создание wrapper: TypeScript-класс с методами для отправки сообщений.
4. Написание теста: деплой, вызов, проверка транзакций.
5. Запуск: npx blueprint test — 200 мс на 10 тестов.

Асинхронность TON vs EVM: как Blueprint упрощает тестирование?

TON — асинхронная платформа: контракты общаются через сообщения, а не транзакции с глобальным состоянием. Нет events; логика результатов — в ответных транзакциях. Blueprint с @ton/sandbox эмулирует этот процесс локально, что делает тесты детерминированными. В EVM тесты работают в 2 раза быстрее (100 мс против 200 мс), но TON гарантирует отсутствие race conditions.

Интеграция с TON Connect и деплой

Blueprint использует NetworkProvider — абстракцию для testnet (tonapi.io) и mainnet. Скрипты запускаются через npx blueprint run deployMyContract с выбором сети. Деплой — отправка сообщения на uninit-адрес. Порядок деплоя важен для связанных контрактов: деплой дочернего → получение адреса → деплой мастера с этим адресом в initial data → верификация тестом.

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

• Настройка Blueprint: инициализация проекта, конфигурация компилятора, sandbox, wrappers.
• Написание тестов: покрытие основных сценариев, интеграция с TON Connect.
• Деплой: настройка скриптов под testnet/mainnet, верификация адресов.
• Документация: инструкции по запуску, описание структуры, CI/CD через GitHub Actions.
• Поддержка: гарантия работоспособности 2 недели после сдачи.

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

Сроки

Базовая настройка — от 4 часов до 1 рабочего дня. С CI/CD и деплоем — 1–2 рабочих дня. Стоимость рассчитывается индивидуально. Закажите консультацию — мы расскажем, как ускорить разработку на TON.

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

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