Программируемый перевод — это кросс-чейн операция, в которой перенос актива между сетями объединён с выполнением бизнес-логики в целевом домене в рамках одного проверяемого сообщения. В отличие от «просто моста» (где актив доставляется, а действия выполняются вручную позже), здесь перевод и целевое действие проектируются атомарно по смыслу: доставили актив → сразу совершили депозит, своп, погашение долга, чеканку представления и т. п.
Термин используется в контексте межсетевых протоколов сообщений (см. Chainlink CCIP), омничейн-активов по модели CCT и архитектур интероперабельности (см. Интероперабельность).
Программируемый перевод (Programmatic Transfer): где это уместно
- Депозит коллатерала в лендинге целевой сети одновременно с переносом токена.
- Автоконверсия поступившего актива в пуле (AMM/PMM) или внесение в фондирование позиции.
- Перевод прав/долей (LP-токенов) с мгновенной «перепривязкой» в целевой сети.
- Клиринг выплат по RWA: поступление средств + запись события погашения/купона.
- Игровые/коммерческие сценарии: доставка актива + немедленное изменение статуса/доступа.
Архитектура по слоям
| Слой | Роль | Что важно |
|---|---|---|
| Сообщение | Доставляет параметры перевода и бизнес-payload A→B | Подписи/кворумы, версии, срок годности, трассировка ID |
| Перенос актива | Минт/разблокировка в целевой сети | Режим *burn/mint* или *lock/mint* per-route, лимиты, учёт предложения |
| Исполнение | Контракт в целевой сети выполняет действие | Идемпотентность, коды статуса, двухфазные операции |
| Наблюдаемость | Метрики и журналы | P50/P95/P99, success ratio, retry rate, queue length, сводки CCT |
Базовые протоколы и модели: CCIP, CCT, Каноничный мост.
Отличия от «обычного моста»
- Не просто «доставить актив», а сразу выполнить заданное действие без ручных шагов.
- Меньше «окон риска»: нет паузы между получением актива и целевым вызовом.
- Контролируемые маршруты и лимиты по передаче/действию, предсказуемый UX.
- Логирование и идемпотентность на уровне сообщения и результата (см. ниже).
Паттерн выполнения в целевой сети
- Проверить маршрут и допустимость отправителя (allow-list, chainId, версию).
- Проверить лимиты: per-tx, per-interval, burst; при срабатывании вернуть статус «отклонено лимитом».
- Обеспечить идемпотентность: один globalMessageID → одно изменение экономики.
- Выполнить двухфазно:
- Фаза учёта: минт/разблокировка актива, запись статуса «готов к действию».
- Фаза бизнес-логики: депозит/своп/погашение и т. п.; по сбою — «мягкий откат» к безопасному состоянию.
- Вернуть код результата и журнал для наблюдаемости.
Подробные инженерные советы для контрактов целевой сети (TON и не только) — см. TON × CCIP и Toolbox.
Режимы переноса актива
| Режим | Когда уместен | Плюсы | Минусы |
|---|---|---|---|
| Burn/Mint | Быстрая надёжная финальность в исходной сети; нет требований к «замку» | Чистый учёт предложения | Требует надёжной верификации «burn» и строгой идемпотентности |
| Lock/Mint | «Длинные» сети, особые регуляторные/операционные требования | Обратимость через «unlock» | Риск и стоимость хранения «замков», аудит кастоди |
Выбор делается per-route в рамках каноничной политики (см. Каноничный мост).
Модель риска и контроль
Идемпотентность. Повтор одного и того же сообщения не должен повторно изменять балансы/состояние. Нужна таблица «messageID → исполнено/хэш».
Финальность. Для вероятностной финальности/L2 используйте повышенные подтверждения и отложенное исполнение крупных сумм.
Лимиты и пауза.
- per-tx, per-interval, burst-пороги;
- режим «пауза маршрута» и «только возвраты» на инцидент;
- белые списки получателей для чувствительных операций.
Наблюдаемость. Отслеживайте latency (P50/P95/P99), success ratio, retry rate, размер очередей, частоту срабатывания лимитов, сводки эквивалентности обращения CCT («сожжено/под замком ↔ сочеканено»). Подробнее — Риски мостов.
Payload сообщения: что передавать
- Идентификаторы: globalMessageID, версия протокола, nonce.
- Параметры перевода: токен/сеть/сумма, адрес получателя, режим (*burn/mint* или *lock/mint*).
- Бизнес-payload: тип действия (deposit/swap/repay/mint-to/…); параметры (пул, срок, мемо, дедлайны, допустимый проскальзывание).
- Политика исполнения: дедлайн, приоритет, требование к цене (см. раздел про цены).
- Метаданные наблюдаемости: трассировка, инициатор, канал.
Ценовая логика и дедлайны
Если действие зависит от цены (депозит с оценкой залога, ликвидация, своп), совместите:
- низкую задержку для триггеров и проверки условий — см. Data Streams;
- ончейн-якоря для аудита и расчётов — см. Streams vs Feeds и Ценовой оракул.
Не «мостите цену как токен» — передавайте значение в сообщении и исполняйте логику локально в целевой сети.
Проектные решения, о которых часто забывают
- Версионирование: поле version в payload; отклоняйте устаревшие версии.
- Dry-run/симуляция: возможность проверить действие без окончательной записи.
- Partial-fail: если действие частично выполнилось — возвращайте чёткий статус и безопасные остатки.
- Retry-политики: экспоненциальный back-off; «переупаковка» payload при повторе.
- Геттеры: прозрачные состояния для фронта/саппорта; коды ошибок и «человеческие» пояснения.
Сравнение с альтернативами
| Подход | Безопасность | UX | Инженерная сложность |
|---|---|---|---|
| Обычный мост + ручные действия | Больше «окон риска» (пауза между шагами) | Дольше, больше шагов пользователя | Ниже на старте |
| Программируемый перевод (сообщение + действие) | Лимиты, пауза, финальность, идемпотентность | Быстро и предсказуемо | Выше (контракты + SRE) |
| Омничейн-актив CCT без действий | Минимум логики в целевом домене | Требуются последующие шаги | Средняя |
Для полноты контекста по CCT/канону см. CCT и Каноничный мост.
Метрики SRE и KPI
- Latency доставки A→B и «время до исполнено» в целевой сети (P50/P95/P99).
- Success ratio и распределение причин отказов (лимит, дедлайн, валидация, газ).
- Retry rate/время до успеха; глубина очередей.
- Срабатывания лимитов и длительность пауз.
- Для CCT — расхождения эквивалентности обращения (алерты «mint ≠ burn+lock»).
Плейбук инцидента
- Выявить затронутые маршруты/токены, оценить объём и хвосты задержек.
- Перевести маршруты в паузу; включить режим «только возвраты».
- Зафиксировать состояние: журналы сообщений, очереди, лимиты, версии.
- Коммуникация статуса и ожиданий восстановления.
- Сверка эквивалентности обращения CCT; корректировка лимитов.
- Канареечный рестарт и пост-мортем.
Частые ошибки и анти-паттерны
- Отсутствие идемпотентности: повторы приводят к двойным действиям.
- Режим «всё можно» по маршрутам: непредсказуемые траектории и рост blast radius.
- Игнор P95/P99: ориентируются на «среднее» время — ошибки ликвидаций и дедлайнов.
- Жёсткая связка на «цену-токен»: вместо передачи значения и проверки в целевой сети.
- Нет «только возвраты»: при инциденте продолжают принимать новые переводы.
Мини-чек-лист внедрения
- Описана каноничная политика: сети, маршруты, режимы, лимиты, пороги финальности.
- Реализованы идемпотентность и двухфазные операции.
- Настроены лимиты per-tx/per-interval/burst, белые списки, режимы паузы.
- Добавлены геттеры состояния, коды ошибок, поля версионирования.
- Включены дашборды SLA и алерты; есть плейбуки инцидента.
- Пройдены деградационные тесты: reorg, out-of-order, газ-шоки, заторы очередей.
FAQ
Это «атомарно» как в одной транзакции? Атомарность здесь семантическая: одно доставленное сообщение инициирует полный цикл «перевод + действие» в целевой сети. Фактическая реализация использует асинхронную модель сообщений и идемпотентность.
Можно ли без переноса активов? Да. Если достаточно лишь логики в целевом домене, используйте только сообщения (см. Интероперабельность).
Как выбрать burn/mint vs lock/mint? Оценивайте финальность/риск маршрута. Быстрые домены — чаще *burn/mint*; «длинные»/регуляторно сложные — *lock/mint*.
Что делать с ценой/проскакиванием? Передавайте дедлайны и допускаемую погрешность в payload, используйте потоки низкой задержки и ончейн-якоря (см. Data Streams и сравнение).
Как измерять «здоровье» перевода? Latency P95/P99, success ratio, retry rate, очередь, частота срабатывания лимитов; для CCT — сводки эквивалентности обращения.