efir369999/montana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
34135456b6
montana/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Atomic-Swap-Протокол.md

12 KiB
Raw Blame History

Atomic Swap Протокол Montana ↔ Monero

Версия: 1.0 draft Тип интеропа: trustless, без bridge, без custodial endpoint, без wrapped токенов

1. Цель

Дать пользователю возможность обменять XMR ↔ TC (Junona) атомарно — либо обмен происходит для обеих сторон, либо не происходит ни для одной. Никто никому не должен доверять.

2. Принципиальная схема

Используется классическая HTLC (Hash Time Lock Contract)-схема, адаптированная под особенности обеих цепей:

Алиса хочет обменять X XMR на Y TC.
Боб хочет обменять Y TC на X XMR.

1. Алиса генерирует secret S, вычисляет H = SHA-256(S).
2. Алиса публикует H публично.
3. Алиса блокирует X XMR на Monero с условием:
   "Боб может потратить если предъявит S таком что SHA-256(S)=H,
    OR Алиса может вернуть после 24 часов".
4. Боб видит блокировку Алисы, проверяет H, блокирует Y TC на Montana с условием:
   "Алиса может потратить если предъявит S таком что SHA-256(S)=H,
    OR Боб может вернуть после 12 часов".
5. Алиса предъявляет S и забирает Y TC на Montana.
   В этот момент S становится публично известен (в Montana блокчейне).
6. Боб видит S в Montana блокчейне, использует его чтобы забрать X XMR на Monero.

Если Алиса не предъявит S в первые 12 часов — Боб откатывает Y TC.
Если Боб не блокирует Y TC в Monero после Алисы — Алиса откатывает X XMR через 24 часа.

Атомарность: либо оба обмена произойдут, либо оба откатятся.

3. Адаптация под Monero (challenges)

3.1 Monero не поддерживает HTLC native

Monero — UTXO с ring signatures, без Turing-complete VM. Прямой HTLC через скрипт невозможен.

Решение через Adaptor Signatures (Adaptor Sigs):

Используется паттерн из Joint Multi-Asset Atomic Swaps (COMIT 2020-2024). Аналог BTC-XMR atomic swap уже работает в production.

Идея:

  1. Вместо HTLC на Monero — adaptor signature: Боб создаёт partially-signed transaction которую может завершить только зная S.
  2. Когда Алиса предъявляет S на Montana чтобы забрать Y TC, S становится публичным.
  3. Боб видит S, завершает adaptor signature, потребляет UTXO Алисы на Monero.

3.2 Адаптация под Montana

Montana поддерживает HTLC через расширение Account Chain:

HTLC Operation:
  - lock_amount: TC
  - hash_target: H = SHA-256(secret)
  - claimer_pk: ML-DSA-65 PK получателя при предъявлении secret
  - refund_pk: ML-DSA-65 PK отправителя при истечении timeout
  - τ_timeout: окно после которого refund возможен

Это требует расширение типов операций на уровне спеки Монтаны (см. 04 Спецификация §«Типы операций»).

4. Полный протокол с PQ-учётом

=== Phase 1: Setup ===
Алиса:
  S ← random(256 bits)
  H = SHA-256(S)
  Sign(H) using ML-DSA-65   # подтверждение что Алиса знает S

Алиса публикует H + signature через off-chain communication channel
(messenger / IRC / etc.) — это ваш choice, не часть протокола.

=== Phase 2: Lock на Monero ===
Алиса публикует Monero transaction:
  - input: X XMR (Алиса owns)
  - output: blocked under spendable-by-knowledge-of-S
  - использует Schnorr adaptor signature pattern

(детали Monero adaptor sig: см. реализацию COMIT xmr-btc-swap)

=== Phase 3: Verify + Lock на Montana ===
Боб видит Monero transaction Алисы.
Боб проверяет hash_target = H, amount = X XMR, structure correct.
Боб публикует Montana HTLC operation:
  - lock_amount: Y TC
  - hash_target: H
  - claimer_pk: Alice_ML-DSA-65_PK
  - refund_pk: Bob_ML-DSA-65_PK
  - τ_timeout: текущее окно + (12 часов / 60 секунд) = +720 окон

=== Phase 4: Алиса забирает TC ===
Алиса публикует Montana claim operation:
  - reveals S
  - signs with Alice_ML-DSA-65_SK
  - Montana verifies SHA-256(S) == H ✓
  - Montana transfers Y TC to Alice's account.
  - S теперь публичен в Montana блокчейне.

=== Phase 5: Боб забирает XMR ===
Боб видит S в Montana блокчейне (читает события window τ_claim).
Боб использует S чтобы завершить Monero adaptor signature.
Боб spends Алисин Monero UTXO → X XMR теперь у Боба.

=== Phase 6: Refund (если что-то пошло не так) ===
Если Алиса не публикует S в первые 720 окон Montana (12 часов):
  Боб публикует Montana refund operation, забирает Y TC обратно.

Если Боб не публикует Monero lock после Алисы:
  Алиса публикует Monero refund (через 24 часа = 1440 окон).

5. Безопасность

5.1 Атомарность

Теорема (informal): при честных Монтане и Monero (валидаторы обеих сетей следуют протоколу), либо обе стороны получают желаемое, либо обе сохраняют исходные средства.

Доказательство опирается на:

  • HTLC на Montana гарантирует что либо Алиса предъявит S и получит Y TC, либо Боб откатит после τ_timeout.
  • Adaptor signature на Monero гарантирует что Боб может завершить swap iff S известен; знание S следует из факта что Алиса опубликовала claim на Montana.
  • Timeout на Monero (24 часа) > Timeout на Montana (12 часов): даёт Алисе window забрать TC до того как её XMR откатится. Это критическое условие.

5.2 Атаки

Атака Защита
Алиса не публикует S Боб откатывает после 12 часов
Боб не лочит TC после XMR Алиса откатывает после 24 часов
Race condition: Алиса claim'ит TC в последний момент перед Боб refund'ом Buffer 12 часов разница timeout'ов
Front-running S в Montana mempool После Алисиного claim'а Боб уже знает S; новых "крадущих" Бобов на Monero нет
Reorganization Montana блокчейна Подождать N окон финальности перед предъявлением (см. 01 Консенсус)

6. Что должно быть на стороне Monero

Реализация на Monero:

  • Wallet RPC расширение или standalone tool который выполняет:
    • Создание adaptor signature lock'а.
    • Проверка blockchain Montana на появление S.
    • Завершение adaptor signature после получения S.

Это можно реализовать как Monero wallet plugin или как standalone bridge daemon работающий рядом с обычным Monero wallet.

Не требует хард-форка Monero. Используются существующие primitives.

7. Что должно быть на стороне Montana

Расширение Account Chain (см. 04 Спецификация):

  • Новый тип операции: HTLCLock.
  • Новый тип операции: HTLCClaim (предъявление S).
  • Новый тип операции: HTLCRefund (после timeout).

Это breaking change в спеке → требует MIP в 12 Управление.

8. Численный пример

Алиса меняет 0.5 XMR на 100 Ɉ TC.

Phase 2 — Алиса лочит 0.5 XMR на Monero:
  size: ~3 КБ tx (стандартный Monero)
  fee: ~0.0001 XMR

Phase 3 — Боб лочит 100 Ɉ TC на Montana:
  size: ~5 КБ tx (стандартный Montana HTLC)
  fee: ~0.001 Ɉ (1 секунда времени, по поокнной модели)

Phase 4 — Алиса claim 100 Ɉ:
  size: ~5 КБ tx
  fee: ~0.001 Ɉ
  reveals S in window τ.

Phase 5 — Боб spends 0.5 XMR using S:
  size: ~3 КБ tx Monero
  fee: ~0.0001 XMR

Total time: ≈ 10 минут (зависит от network confirmations).
Total fees: ~0.0002 XMR + ~0.002 Ɉ.

9. Какие проблемы остались

  • Atomicity при partition. Если Montana или Monero сеть split'ится в момент swap — может произойти неоднозначность. Стандартная защита — длительный timeout.
  • Frontrunning Алисы со своим transaction. Mitigation — публикация S через коммитмент со временем reveal'а.
  • MEV на Montana. Если оператор-победитель окна смотрит на содержимое его блока, он мог бы reorder. Лотерея определяется детерминированно из VDF — тяжело manipulate (см. 07 Модель угроз §2.10).

10. Roadmap реализации

См. Дорожная карта, milestone M11:

  • Спецификация HTLC operations в Montana (MIP-001).
  • Reference implementation на Rust в mt-htlc crate.
  • Adaptor signature wrapper для Monero (либо использовать существующий xmr-btc-swap код, переориентировав на Montana вместо Bitcoin).
  • Тестовая сеть atomic swap mos↔Monero stagenet.
  • Audit обеих стороны: Monero adaptor sig + Montana HTLC.
  • Mainnet activation.

11. Связанные документы

12. Источники

  1. COMIT (2020). XMR-BTC Atomic Swap. github.com/comit-network/xmr-btc-swap.
  2. Pieter Wuille (2018). Schnorr Signatures and Adaptor Signatures.
  3. Andrew Poelstra (2017). Mimblewimble. (Adaptor sigs theory).
  4. Tairi, E., Moreno-Sanchez, P., Maffei, M. (2021). A2L: Anonymous Atomic Locks for Scalability in Payment Channel Hubs. IEEE S&P.
  5. Hash Time Locked Contracts (HTLC) — Bitcoin Wiki.