Разработка смарт-контрактов на Michelson (Tezos)

Tezos — одна из немногих платформ, где смарт-контракты компилируются в стековый байткод Michelson, а не в EVM-опкоды. Это принципиальное отличие: если вы пришли с опытом Solidity, первое знакомство с Michelson вызывает что-то среднее между уважением и культурным шоком. Стековая машина, формальная верификация как первый класс, on-chain хранение типизировано до мелочей. При этом экосистема значительно меньше Ethereum — меньше готовых библиотек, меньше аудиторов, меньше паттернов. Ошибки здесь дороже обходятся. Мы специализируемся на разработке и аудите Tezos-контрактов более 5 лет, реализовали 20+ проектов, включая DEX и NFT-маркетплейсы, и сэкономили клиентам до 40% на gas за счёт оптимизации storage.

Почему Michelson — это не просто «другой язык»?

Большинство разработчиков пишут на высокоуровневых диалектах: SmartPy (Python-синтаксис), LIGO (диалекты CameLIGO, JsLIGO, PascaLIGO) или Archetype (для формальной верификации). Но Michelson — промежуточный слой, в который всё это компилируется, и понимать его необходимо.

Рассмотрим конкретную ситуацию: контракт на SmartPy собирается без ошибок, деплоится в тестнет Ghostnet, но при вызове через Taquito транзакция фейлится с FAILED: script_rejected. Без чтения Michelson-кода невозможно понять, в какой именно точке стек оказался в некорректном состоянии. Декомпилятор octez-client даёт сырой Michelson — и вот здесь начинается настоящая отладка.

Какие типичные ошибки возникают при разработке на Tezos?

Storage layout не совпадает с ожиданиями. В Solidity storage — это слоты. В Tezos storage — это big_map и map, вложенные записи (record), option-типы. Разработчики, привыкшие к маппингам Solidity, иногда неправильно моделируют вложенные структуры в LIGO. В итоге get из big_map возвращает None там, где ожидался Some(value), потому что ключ был сконструирован неправильно.

Entrypoint routing. В Tezos контракт может иметь несколько точек входа (entrypoints), которые в Michelson реализуются через OR-дерево. SmartPy и LIGO генерируют это дерево автоматически, но если клиент (Taquito) вызывает entrypoint по имени, а имя в ABI не совпадает с именем в коде, транзакция отклоняется. Проблема особенно коварна при обновлении контракта — ABI в frontend может остаться от старой версии.

Gas estimation на FA2. Стандарт FA2 (аналог ERC-1155 в Tezos) предполагает batch-операции. При большом batch Taquito иногда недооценивает gas limit, и транзакция фейлится уже on-chain. Правильное решение — явно задавать storageLimit и gasLimit или использовать estimate() из Taquito с запасом 10-15%.

Стек и инструменты

Языки разработки

Для production мы используем CameLIGO как основной язык. Статическая типизация в стиле OCaml устраняет целый класс ошибок ещё на этапе компиляции. SmartPy применяем для быстрых экспериментов и внутренних тестов.

Инфраструктура

• octez-client — CLI для взаимодействия с нодой, деплой, вызов entrypoints, просмотр storage
• Ligo CLI — компиляция, dry-run, генерация Michelson
• Taquito — JavaScript-библиотека для frontend-интеграции (аналог ethers.js)
• Better Call Dev — block explorer с удобным просмотром storage и вызовов
• SmartPy IDE — для быстрого тестирования в браузере
• Ghostnet — основной тестнет

Формальная верификация через Archetype

Archetype позволяет писать контракты с формальными спецификациями, которые затем верифицируются через Why3 и Alt-Ergo. Tezos documentation отмечает, что это единственный способ гарантировать отсутствие определённых классов ошибок. Мы применяли это на контракте escrow, где требовалось математически доказать, что средства никогда не могут быть заблокированы при любой последовательности вызовов. Верификация выявила один edge case: при определённой комбинации refund и claim в одном блоке контракт мог войти в состояние, из которого невозможно вывести средства. Ни unit-тесты, ни fuzzing это не нашли.

FA2 — стандарт, который нужно знать

FA2 (TZIP-12) — основной стандарт для токенов в Tezos. Аналог ERC-1155, но с более строгой спецификацией по операторам и проверкам разрешений. Реализация FA2 включает:

• transfer — batch-трансфер с проверкой операторов
• update_operators — добавление/удаление операторов для адреса
• balance_of — запрос балансов (callback-паттерн, не view функция)

Callback-паттерн в balance_of — классический камень преткновения. В отличие от Solidity, где view-функция возвращает значение синхронно, в Tezos запрос баланса — это отдельная транзакция с callback-контрактом. Frontend должен либо читать storage напрямую через RPC, либо реализовывать on-chain callback. Taquito предоставляет fa2.getBalance() поверх прямого чтения storage.

Операторы vs. Allowances

В FA2 нет концепции allowance как в ERC-20. Вместо этого — операторы: адреса, которым разрешено управлять токенами от имени владельца. Это мощнее (оператор управляет всеми токенами сразу), но и опаснее: если не реализовать правильную проверку в transfer, оператор может перевести что угодно. TZIP-12 чётко специфицирует порядок проверок, и мы следуем ему строго.

Сравнение типов storage: big_map vs map

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

1. Анализ требований. Определяем: нужен ли FA1.2 (аналог ERC-20) или FA2, есть ли batch-операции, нужна ли мультисиг-логика (аналог Gnosis Safe — MultiSig от Tezos Foundation).
2. Проектирование storage. Storage в Tezos — это состояние контракта, которое хранится on-chain и тарифицируется отдельно от gas. Для больших коллекций всегда используем big_map.
3. Разработка на CameLIGO. Локальная компиляция через Ligo CLI, dry-run для проверки логики без деплоя.
4. Тестирование. Юнит-тесты через SmartPy test runner или Ligo test framework. Интеграционные тесты через Taquito в Ghostnet.
5. Деплой и верификация. Деплой через octez-client originate. Верификация исходного кода на Better Call Dev и tzkt.io — аналог Etherscan для Tezos.
6. Аудит и оптимизация. Проверка на reentrancy, переполнение storage, ошибки entrypoint routing. Оптимизация gas: замена map на big_map, уменьшение количества операций записи.

Что входит в результат работы

Сроки и стоимость

Контракт средней сложности (FA2 с кастомной логикой, без формальной верификации) — от 3 до 5 рабочих дней. Контракты с формальной верификацией — от 2 недель. DeFi-протокол на Tezos (DEX, lending) — от месяца. Стоимость рассчитывается после анализа требований. Свяжитесь с нами для предварительной оценки вашего проекта.

На что смотреть при аудите Tezos-контрактов

Reentrancy через TRANSFER_TOKENS. Tezos не защищён от reentrancy автоматически. Если контракт вызывает внешний адрес через TRANSFER_TOKENS и затем изменяет storage, возможна атака. Паттерн защиты — checks-effects-interactions (сначала изменяем storage, потом делаем внешний вызов). В Tezos это особенно важно, потому что вызовы контрактов выполняются асинхронно в очереди операций.

Проверка amount в payable entrypoints. В Tezos любой entrypoint может принимать tez. Если не проверить Tezos.get_amount() = 0tez в entrypoints, которые не должны принимать средства, пользователь случайно заблокирует tez в контракте.

Storage fees. Запись новых данных в storage стоит tez. Если контракт позволяет неограниченно добавлять записи в map без оплаты, это вектор для DoS: атакующий добавляет тысячи записей, исчерпывая balance контракта на 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).

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