Анализ компенсирующих транзакций, частичного расчёта и ограничений атомарности при межсетевых платежах
Многие организации и разработчики по-прежнему считают, что успешное подтверждение транзакции в сети отправителя доказывает завершение платежа. В межсетевых системах это часто не так.
При изучении технической документации и наблюдении за базовым поведением системы в контролируемых условиях постоянно проявляется одна закономерность: списание в исходной сети может успешно завершиться, а на следующем этапе в сети назначения всё ещё может произойти сбой. В таком случае средства не возвращаются автоматически. Обычно система выполняет **компенсирующую транзакцию**.
Частичная атомарность
В официальной документации Rayls (*Отправка транзакций Enygma* и *Как работает Enygma*) чётко описаны границы атомарности:
- Вызов в исходной сети атомарен: сжигание и запрос на перевод либо завершаются успешно вместе, либо вместе завершаются неудачей.
- Каждое отдельное направление перевода атомарно: выпуск токенов и все программные шаги в рамках этого направления либо завершаются успешно вместе, либо вместе завершаются неудачей.
- Все направления перевода в рамках одного платежа **не являются** атомарными. Они могут завершаться независимо друг от друга.
В документации прямо сказано: «Сбои компенсируются, а не откатываются». Транзакция в Hub и выпуск токенов в сети назначения — это отдельные транзакции. Если выпуск токенов или программный шаг в сети назначения завершается неудачей, ретранслятор запускает компенсирующую транзакцию, чтобы вернуть средства отправителю. Это не одна атомарная транзакция между сетями.
До фактического зачисления возврата баланс отправителя в исходной сети остаётся уменьшенным на сумму, перевод которой завершился неудачей.
Что такое компенсирующая транзакция?
Компенсирующая транзакция — это **новая, отдельная** транзакция, созданная для исправления последствий сбоя. Это не откат исходной транзакции.
Согласно документации RaylsEnygmaHandler, если какой-либо программный шаг откатывается, всё направление перевода (включая выпуск токенов) завершается неудачей. Затем ретранслятор возвращает средства отправителю в исходной сети с помощью компенсирующего механизма. Возврат отображается под **тем же идентификатором ссылки** и записывается в исходной сети со статусом `RECEIVED`, а не как простой откат исходного списания.
Простой пример, соответствующий описанному в документации поведению:
- В исходной сети списывается 10.
- В одну из сетей назначения успешно поступает 4.
- В другой сети назначения выполнение завершается неудачей.
- Отдельная компенсирующая транзакция возвращает отправителю 6.
Итог: доставлено 4 + возвращено 6 = 10. Исходная транзакция в исходной сети по-прежнему записана как успешная.
Схемы
Базовый процесс:
Атомарность и несколько направлений перевода:
Пример частичного расчёта:
Практические риски, на которые стоит обратить внимание
В документации и наблюдениях в контролируемых средах часто упускают из виду несколько моментов:
1. Возврат средств происходит не мгновенно
В самой документации Rayls отмечается, что до зачисления возврата баланс отправителя остаётся уменьшенным. Задержки ретранслятора или проблемы с генерацией доказательства могут привести к тому, что средства останутся в ожидании дольше, чем предполагалось.
2. Сверку необходимо выполнять отдельно для каждого направления
Одной квитанции исходной сети недостаточно. Необходимо сопоставить сумму, списанную в исходной сети, сумму, поступившую в каждую сеть назначения, сумму, перевод которой завершился неудачей, и сумму, фактически возвращённую посредством компенсирующей транзакции (обычно под тем же идентификатором ссылки).
3. Зависимость от внесетевых компонентов
Обнаружение сбоев и инициирование возврата часто зависят от ретрансляторов. Даже при локальном тестировании могут появляться предупреждения, связанные с фиксацией баланса или генерацией доказательства. В продуктивной среде эти риски выше.
4. Результаты контролируемого тестирования ≠ гарантии для продуктивной среды
Стабильная работа в лабораторных условиях при специально вызванных сбоях не гарантирует такого же поведения в продуктивной среде с параллельной нагрузкой, проблемами сети или несогласованностью состояний.
Заключение
Успешная квитанция в исходной сети доказывает лишь то, что списание было зафиксировано. Она не доказывает, что средства поступили в каждую сеть назначения, и не подтверждает, что какая-либо неудавшаяся часть была возвращена.
Успешное выполнение в исходной сети, расчёт в сети назначения и компенсирующий возврат — связанные события, но **это не одно и то же событие**. Понимание этого различия важно при проектировании и эксплуатации межсетевых расчётов.
В официальной документации Rayls этот компенсирующий механизм уже описан открыто. Важно не считать результаты, полученные в контролируемой среде, полным доказательством надёжности в продуктивной среде.
---
Отказ от ответственности:
Эта статья представляет собой анализ, основанный на общедоступной документации Rayls и технических наблюдениях в контролируемых средах. Это не официальный аудит, не инвестиционная рекомендация и не гарантия поведения какой-либо системы в продуктивной среде. Читателям следует проверять сведения непосредственно по официальной документации.
Источники
- Отправка транзакций Enygma: https://docs.rayls.com/docs/send-enygma-transactions
- Как работает Enygma: https://docs.rayls.com/docs/how-enygma-works
- RaylsEnygmaHandler: https://docs.rayls.com/docs/raylsenygmahandler