montana/Формальная Документация/13 Приватный Финансовый Слой Монеро-Монтана/Atomic-Swap-Протокол.md

218 lines
12 KiB
Markdown
Raw Normal View History

2026-05-04 07:08:51 +03:00
# 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](https://github.com/comit-network/xmr-btc-swap) (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 Спецификация](../04%20Спецификация%20Протокола/) §«Типы операций»).
## 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 Консенсус](../01%20Консенсус/)) |
## 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 Спецификация](../04%20Спецификация%20Протокола/)):
- Новый тип операции: `HTLCLock`.
- Новый тип операции: `HTLCClaim` (предъявление S).
- Новый тип операции: `HTLCRefund` (после timeout).
Это **breaking change** в спеке → требует MIP в [12 Управление](../12%20Управление%20и%20Обновления/Governance.md).
## 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](../07%20Модель%20Угроз/)).
## 10. Roadmap реализации
См. [Дорожная карта](Дорожная-Карта.md), 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. Связанные документы
- [Архитектура](Архитектура.md) — общий контекст приватного слоя.
- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) — Path 2 включает совместное ревью этого протокола.
- [04 Спецификация](../04%20Спецификация%20Протокола/) — куда добавятся HTLC operations.
- [12 Управление](../12%20Управление%20и%20Обновления/) — MIP-процедура.
## 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.