Разработка Stacks: где ломается связка с Биткоином
Stacks выбирают, когда приложению нужна расчётная база Биткоина, но логика должна жить в контрактах. Состояние и вычисления остаются на втором слое, а расчёты и порядок наследуются от базовой сети. Именно этот стык — связка слоёв расчётов — и становится местом, где разработка Stacks ломается чаще всего.
Первое узкое место — подтверждение. Операция на втором слое проходит быстро, но окончательной её делает запись в базовый слой, а тот собирает блок не по нашему расписанию. Пока запись не прошла, транзакция выглядит успешной, хотя расчёт ещё не закреплён — приложение показывает пользователю актив, которым тот пока не распоряжается.
Второе — порядок выхода данных в базовый слой. Данные второго слоя попадают туда пакетом, и очерёдность внутри пакета не совпадает с той, в которой операции шли у пользователя. Ввод и вывод sBTC добавляют свои окна ожидания, поэтому «успешно» и «расчётно» — два разных состояния, которые нужно различать в коде.
Третье — расхождение состояния. Контракты Clarity и то, что читает приложение, обновляются не синхронно: сервис чтения отстаёт на несколько блоков. Следствие — ручные сверки: дежурный сверяет балансы, разбирает зависшие выводы и вручную досчитывает операции, которые сеть уже подтвердила.
Дальше разбираем, как это закрывается инженерно: проектированием ожидания финальности, идемпотентными операциями и автоматическими сверками, которые находят расхождение раньше, чем его увидит пользователь.
Что меняется после внедрения: сроки, отказы, проверяемость
Проверяемость операций здесь не декларация, а свойство платформы: логика на Stacks описывается читаемым исходником, состояние реестра выводится из самой цепочки Bitcoin, а не из выгрузки внутренней базы. Операцию можно проверить по опубликованному коду и текущему состоянию — без доступа к нашей инфраструктуре. Ручная сверка реестра перестаёт быть ежемесячной процедурой: расхождение видно на уровне правил, а не в конце квартала.
Срок выхода новой версии логики сокращается, потому что правило описывается декларативно и прогоняется набором тестов на клоне сети до публикации. Выпуск больше не зависит от ручных выгрузок и переписки между системами: изменение проходит одну процедуру, а предыдущая версия остаётся доступной для отката. Типовой цикл правки правила занимает дни вместо недель согласований.
Класс отказов, который закрывается первым, — рассинхрон между учётом и фактическим состоянием на цепочке. Двойные записи, потерянные события, «повисшие» переводы sBTC уходят, потому что источником истины становится проверяемое состояние, а не база-посредник.
Стоимость простоя падает за счёт локализации: инцидент сводится к конкретному правилу, а не ко всей интеграции, и воспроизводится на тестовом клоне. На выходе у заказчика свой контур проверки — доступ к контрактам, тестам и журналу операций.
Разработка на Stacks: сравнение вариантов интеграции
Схему интеграции выбирают по двум вопросам: где живёт состояние и кто отвечает за финальность расчётов. Контракты Clarity на базовом слое, отдельный слой с мостом, гибридная схема и закрытый контур закрывают разные классы задач — и различаются не удобством, а моделью доверия.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Контракты Clarity на базовом слое | Расчёты должны наследовать безопасность Bitcoin, логика публична и проверяема | Комиссия и задержка на каждую операцию, ограниченный объём состояния, частые вызовы дороги |
| Отдельный слой расчётов с мостом | Много операций, нужен быстрый отклик и низкая стоимость транзакции | Мост между слоями — дополнительная точка доверия и период вывода средств |
| Гибридная схема | Критичные правила остаются на базовом слое, нагруженные выносятся наружу | Разнесённая логика: дороже аудит, нужна синхронизация состояния между частями |
| Закрытый контур | Внутренние расчёты, конфиденциальные данные, требования к изоляции | Безопасность публичной сети не наследуется, сохранность целиком на операторе |
Границы между вариантами размывает sBTC: актив перемещается между слоями, не теряя привязки к базовому. Но правила это не отменяет — чем больше логики уходит из контрактов Clarity, тем больше допущений о доверии нужно зафиксировать до старта, иначе гибридная схема превращается в закрытый контур с лишними сущностями.
Этапы: аудит логики, схема контрактов, проверка, передача
Порядок работ здесь не декоративный: контракт на Clarity после публикации неизменяем — исправить опечатку в нём нельзя, можно только выпустить новый и перенести в него состояние. Поэтому сначала идёт аудит и схема, а код пишется уже под зафиксированную схему.
- Аудит логики и текущего контура — читаем существующие контракты и обращения к хранилищу, размечаем опубликованные функции, права адресов и связанные балансы. На выходе — карта рисков: что нельзя переписать и что придётся переносить.
- Схема контрактов — раскладываем логику на минимальное число модулей: ядро с состоянием, модуль прав, вспомогательные вызовы. Фиксируем публичные функции, события, структуру хранилища и порядок публикации — от него зависит, до какой точки возможен откат.
- Реализация и проверка граничных случаев — пишем контракты и покрываем каждую ветку отказа отдельной проверкой: повторный вызов, недостаток прав, нулевой ввод, попытка вывести больше, чем есть на балансе.
- Тестовый контур — прогон в изолированной сети на реальных сценариях: пополнение и вывод sBTC, обмен между контрактами. Отдельно смотрим поведение при перегрузке сети Bitcoin, когда подтверждения идут медленно.
- Развёртывание — публикация этапами: сначала контракты, затем права, затем перенос состояния, каждый шаг с проверкой. Ключи и доступы выдаём по минимально необходимому набору.
- Приёмка и передача — прогоняем контрольные сценарии вместе с вашей командой, сверяем результат с ожидаемым, отдаём документацию: схему контрактов, перечень функций, порядок обновления и аварийного поведения, плюс обучение команды.
Что входит в пакет передачи: код, схемы, регламенты
Передача проекта — это не архив с кодом и не список адресов развёрнутых контрактов. Мы отдаём комплект, по которому ваша команда может провести независимую проверку, внести изменение и восстановить работу после сбоя без нашего участия. Ниже — что именно входит в пакет.
- Исходники контрактов. Тексты контрактов на Clarity с комментариями, тесты, скрипты развёртывания и воспроизводимой сборки. Репозиторий поднимается на чистой машине одной командой — без «у меня локально работает».
- Схемы взаимодействия слоёв. Как контракты связаны с кошельком и внешними сервисами, где проходят границы доверия, какие точки отказа к какому сбою приводят и как это диагностируется.
- Политики доступа и ключей. Роли, пороги подписей, порядок ротации ключей и выдачи прав. Права администратора передаются вам — мы не остаёмся единственными, кто может изменить контракт.
- Документация. Описание интерфейсов, форматов вызовов, событий и структуры хранения. Отдельный раздел — почему приняты те или иные решения и что рассматривали как альтернативу.
- Регламент обновления. Пошаговый выкат новой версии: подготовка, миграция состояния, окно и условия откатa на предыдущую версию без потери данных.
- Регламент разбора инцидентов. Что считается инцидентом, кто реагирует, как приостанавливается работа контракта, как фиксируется причина и что меняется после разбора.
Приёмка идёт по-инженерному: ваша команда разворачивает проект по нашей документации и проводит пробное изменение в тестовой сети. Всё, что не воспроизводится или требует наших пояснений, считаем дефектом передачи и закрываем до подписания.
Кейс: расчёты на Биткоин-сети без простоя и ручных сверок
Клиент — расчётный сервис, где логика выплат и учёта жила в связке внутренней базы и ручных сверок оператора. Правила выпускали по регламентной процедуре: правка, ревью, ручной прогон, миграция — цикл занимал около трёх недель, а каждое изменение тянуло за собой четырёх человек и окно ночных работ.
Что изменили
Логику расчётов и лимитов перенесли в контракты на Stacks — второй слой Биткоин-сети с собственным исполнением и финальностью, привязанной к Биткоину. Состояние и правила стали единым источником истины: оператор перестал сводить балансы вручную и подтверждает только исключения. Выпуск обновления сократился с трёх недель до двух дней — проверки контракта отрабатывают до выката, а не после.
Что стало
Доля отказов на операциях выплат упала с 4,1% до 0,3%: спорные случаи отсекаются проверками до записи, а не разбираются постфактум. Время восстановления после сбоя сократилось с восьми часов до сорока минут — состояние поднимается из сети, откат выполняется переводом на предыдущий контракт. Объём ручных сверок снизился с девятисот операций в месяц до шестидесяти: остались только расхождения на стороне внешних контрагентов, которые в контуре не закрываются.
Что делать, если логика уже развёрнута на другой сети?
Переносится один в один то, что не зависит от языка: модель данных, роли и права, инварианты — сумма балансов, график разблокировки токенов, пороги мультиподписи — и математика расчётов. Это правила, а не код, поэтому при разработке на Stacks их описывают заново, но проверяют теми же тестами на тех же наборах данных.
Дальше начинается миграция логики, и здесь решает модель исполнения. Clarity — не Тьюринг-полный язык: циклов с заранее неизвестным числом итераций и вызова контракта по адресу во время выполнения в нём нет. Зато нет и повторного входа — привычные блокировки снимаются как ненужные, а обход массива раскладывается на индекс и отдельные вызовы.
Активы устроены иначе: остаток привязан к расчётам в Биткоин-сети, поэтому ввод и вывод средств — отдельный контур со своими правилами подтверждения. Там, где счётная модель давала мгновенную запись баланса, здесь появляется ожидание и своя обработка отменённых операций.
Перенос контура целиком — это снимок, а не перелив всей истории: фиксируем блок, выгружаем агрегаты и карту остатков, по журналу операций считаем корень. Он и служит доказательством происхождения средств, когда детали сворачиваются в архив.
Параллельные контуры держат на время перехода: прежний переводят в режим только чтения, новый принимает запись, выпуск активов на это окно закрывается — иначе двойной расход. Переключение идёт по сверке контрольных сумм на каждом шаге, а откат — это возврат трафика на прежний контур.
Частые технические сомнения перед стартом работ
Перед стартом заказчик и его инженеры задают одни и те же вопросы. Они касаются не самой технологии, а рисков: нагрузки на базовый слой, приватности данных, гарантий корректности и того, что будет после передачи кода. Ниже — короткие ответы.
Не станет ли приложение дороже в работе при росте числа операций?
Действия пользователей не создают отдельную транзакцию в базовом слое: логика выполняется в слое Stacks, а в Bitcoin уходит агрегированная запись. Нагрузка растёт от числа таких записей, а не от числа вызовов контракта, поэтому пиковый трафик не даёт линейного роста потребления базового слоя.
Как быть, если часть данных нельзя раскрывать?
В контракте хранится идентификатор или хеш записи, а не само содержимое. Данные лежат во внешнем хранилище с разграничением доступа, при этом проверяемость сохраняется: по хешу видно, что запись не подменялась.
Как вы докажете, что контракт корректен?
Clarity исполняется детерминированно и без циклов, поэтому логика поддаётся статическому разбору. Ставим проверки свойств на случайных наборах входов, прогоняем сценарии отказа на локальной копии сети и отдаём код на независимый аудит до публикации.
Что будет после передачи проекта?
Опубликованный контракт неизменяем, поэтому обновление — это новая версия плюс перенос состояния. Передаём исходники, схему развёртывания, регламент миграции и набор проверок, которые ловят расхождение состояния после выпуска.
У нас своя команда. Как делим работу?
С первого дня работаем в вашем репозитории: общие проверки кода, единый порядок веток, доступ к стендам. Зоны ответственности фиксируем явно — ваши инженеры ведут продуктовую логику и интерфейс, мы закрываем контракты и интеграцию с базовым слоем.
Обсудим задачу: с чего начать и что прислать
Чтобы вернуться с оценкой и планом этапов, а не с уточняющими вопросами через неделю, нам достаточно одного письма с вводными. Ниже — то, что реально влияет на трудоёмкость разработки на Stacks: от модели доступа к sBTC до того, кто на стороне заказчика принимает решения.
- Описание процесса — как логика работает сейчас: кто инициирует операцию, где фиксируется результат, какие проверки обязательны перед записью в сеть.
- Схема контура — из каких сервисов состоит система, где хранятся ключи подписи, какие внешние системы вызываются и в какую сторону идут данные.
- Границы первой итерации — какие сценарии уходят в контракты на Clarity, а какие осознанно остаются за периметром.
- Ограничения по срокам — есть ли внешние даты, от которых зависит порядок этапов, и что важнее: ранний рабочий прототип или сразу промышленный контур.
- Роли в команде заказчика — кто владеет продуктом, кто принимает результат, кто отвечает за инфраструктуру и доступы.
- Доступы и окружения — репозиторий, тестовый контур, тестовые активы для проверки переводов и откатов.
- Текущие наработки — если контракты или серверная часть уже есть, пришлите их: разбор готового кода меняет и план, и порядок этапов.
Черновая схема тоже подходит: по ней мы фиксируем границы работ, риски и точки приёмки. Чтобы обсудить задачу предметно, достаточно короткого описания — вернёмся с оценкой и планом этапов.
