sync 2026-05-04T04:08:51Z
This commit is contained in:
parent
7e57375409
commit
34135456b6
@ -0,0 +1,217 @@
|
||||
# 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.
|
||||
@ -0,0 +1,41 @@
|
||||
# Монеро-Монтана — приватный финансовый слой
|
||||
|
||||
**Версия:** 1.0 draft
|
||||
**Статус:** 🟡 Архитектура готова, реализация — research roadmap
|
||||
|
||||
## Принципиальная идея
|
||||
|
||||
Два слоя с чёткими ролями:
|
||||
|
||||
- **Montana (TimeChain)** — базовый слой: время, консенсус, присутствие, эмиссия монеты времени Junona (1 Ɉ = 1 секунда). Каноническая упорядоченность всегда **публична**.
|
||||
- **Монеро-Монтана** — приватный финансовый слой поверх: транзакции с приватностью отправителя, получателя, суммы. Опт-ин для пользователей которым приватность нужна.
|
||||
|
||||
Это **не** wrapped Monero и **не** копия Monero-кода. Это **архитектурное наследие Monero** (концепции ring signatures, stealth addresses, range proofs) с **постквантовыми примитивами Монтаны**.
|
||||
|
||||
## Документы папки
|
||||
|
||||
1. [Архитектура](Архитектура.md) — полная техническая спецификация приватного слоя
|
||||
2. [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) — публичное приглашение к диалогу
|
||||
3. [Постквантовые замены](Постквантовые-замены.md) — какие PQ-примитивы заменяют классическую Monero-крипту
|
||||
4. [Atomic Swap протокол](Atomic-Swap-Протокол.md) — interop Montana↔Monero без моста
|
||||
5. [Дорожная карта](Дорожная-Карта.md) — фазы реализации
|
||||
|
||||
## Архитекторская позиция в одну строку
|
||||
|
||||
Уважение к Monero как proven privacy infrastructure + жёсткое следование PQ-only invariant'у Монтаны = два пути одновременно: краткосрочный atomic swap (interop, ноль моста-уязвимостей) + долгосрочный native PQ-private layer (architecture inspired by Monero, primitives PQ-only).
|
||||
|
||||
## Что НЕ делаем (важно отделить)
|
||||
|
||||
- ❌ **Wrapped Monero на Монтане через мост.** Мосты — крупнейший класс уязвимостей DeFi (Wormhole $325M, Ronin $625M, Nomad $190M). Не делаем.
|
||||
- ❌ **Адаптация Monero-кода (ring signatures Ed25519, bulletproofs SECP).** Нарушает PQ-only Монтаны. Не делаем.
|
||||
- ❌ **Захват бренда «Monero on …»** без диалога с сообществом. Хотим **сотрудничества**, не паразитизма.
|
||||
|
||||
## Что делаем
|
||||
|
||||
- ✅ **Atomic swap** Montana ↔ Monero — короткий путь к interop без моста.
|
||||
- ✅ **Native PQ-private layer** на Монтане — приватные транзакции TC с лattice-based примитивами.
|
||||
- ✅ **Открытый вызов Monero** — публичный документ-приглашение к со-разработке.
|
||||
|
||||
## Приоритет
|
||||
|
||||
Сначала atomic swap (M11–M12 milestones, после M9–M10 mainnet readiness). Потом PQ-private layer как parallel research track.
|
||||
@ -0,0 +1,184 @@
|
||||
# Архитектура приватного финансового слоя Монеро-Монтана
|
||||
|
||||
**Версия:** 1.0 draft
|
||||
**Базовый источник:** Montana Protocol v35.25.0; Monero whitepaper (Saberhagen 2013) + RingCT (Noether 2015) + Bulletproofs (Bünz et al. 2018)
|
||||
|
||||
## 1. Цель
|
||||
|
||||
Дать пользователю Монтаны опт-ин режим **приватных** переводов TC (Junona) — приватность отправителя, получателя, суммы — без отказа от постквантовых примитивов сети.
|
||||
|
||||
## 2. Что такое «приватность» (формально)
|
||||
|
||||
Базируется на трёх независимых ortho-свойствах от Monero:
|
||||
|
||||
| Свойство | Смысл | Monero классический | Монтана PQ-эквивалент |
|
||||
|----------|-------|---------------------|------------------------|
|
||||
| **Sender privacy** | Невозможно установить какой из K возможных аккаунтов сделал перевод | Ring signatures (CLSAG, K=11) | Lattice ring signatures (см. [Постквантовые замены](Постквантовые-замены.md)) |
|
||||
| **Recipient privacy** | Получатель не виден на цепи; нет связи с его публичным адресом | Stealth addresses (one-time keys) | PQ stealth addresses через ML-KEM-768 + DH-style derivation |
|
||||
| **Amount privacy** | Сумма перевода скрыта; виден только zero-knowledge proof что сумма ≥ 0 и ≤ доступного баланса | Pedersen commitments + Bulletproofs | Lattice commitments + lattice-based range proofs |
|
||||
|
||||
## 3. Архитектурные слои Монеро-Монтана
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────┐
|
||||
│ Прикладной слой (Anchor для приложений) │
|
||||
├─────────────────────────────────────────────────────┤
|
||||
│ Приватный слой Монеро-Монтана │
|
||||
│ - Опт-ин «private mode» на уровне аккаунта │
|
||||
│ - Lattice ring sigs / PQ stealth / PQ range proofs │
|
||||
├─────────────────────────────────────────────────────┤
|
||||
│ Public Account Chain (текущая Монтана v35.25.0) │
|
||||
│ - Прозрачные TC переводы, NodeChain, AccountChain │
|
||||
├─────────────────────────────────────────────────────┤
|
||||
│ TimeChain (VDF + Proof of Time) │
|
||||
│ - Каноническая упорядоченность по τ-окнам │
|
||||
│ - ВСЕГДА ПУБЛИЧНА (без приватности) │
|
||||
└─────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
**TimeChain не приватизируется.** Каноническое время и порядок окон — глобальный публичный ресурс. Приватность только на уровне содержимого транзакций аккаунта в опт-ин режиме.
|
||||
|
||||
## 4. Опт-ин модель
|
||||
|
||||
Каждый аккаунт может иметь два режима:
|
||||
|
||||
- **Public mode (default)** — текущее поведение Монтаны: прозрачные транзакции, видимый баланс, видимые отправитель/получатель/сумма. Это сохраняется без изменений.
|
||||
- **Private mode (opt-in)** — аккаунт включает приватный режим и с этого момента его транзакции уходят в Монеро-Монтана слой с приватностью.
|
||||
|
||||
Переход public→private — односторонний на уровне транзакции (баланс ушедший в private может вернуться публично только через специальную операцию reveal). Эта асимметрия защищает от смешения цепей и упрощает анализ безопасности.
|
||||
|
||||
## 5. Ключевые примитивы
|
||||
|
||||
### 5.1 Lattice Ring Signatures (sender privacy)
|
||||
|
||||
Заменяет Monero CLSAG. Подписант доказывает что он один из K=11 потенциальных подписантов (anonymity set) без раскрытия какой именно. Постквантовая реализация — research direction MatRiCT (Esgin-Steinfeld-Sun 2019), MatRiCT+ (2022), последующие лattice-based ring signatures.
|
||||
|
||||
**Параметры:**
|
||||
- Anonymity set K = 11 (как в Monero post-2022).
|
||||
- Размер подписи: пока в research-mode 5–20 КБ (vs 0.5 КБ в Monero CLSAG). Это значимый рост, нужна оптимизация.
|
||||
- Бит безопасности: NIST L3 (≥192).
|
||||
|
||||
**Открытый вопрос:** есть ли уже готовая, проверенная PQ ring signature schema с разумным размером? Текущее состояние research — mid-2020s, схемы существуют, но в production-grade аудите ни одна.
|
||||
|
||||
### 5.2 PQ Stealth Addresses (recipient privacy)
|
||||
|
||||
Заменяет Monero one-time addresses. При публикации публичного адреса получателя `R = Hash(view_key, spend_key)`, отправитель генерирует `r = random`, `R' = R + Hash(r·view_key)·G`, посылает на `R'` + `r·G` как nonce. Получатель сканирует все транзакции и проверяет `R = R' - Hash(view_key·r·G)·G`.
|
||||
|
||||
**PQ адаптация через ML-KEM-768:**
|
||||
- Получатель публикует view-public-key и spend-public-key (PQ).
|
||||
- Отправитель использует ML-KEM-768 encapsulation: получает (ciphertext, shared_secret).
|
||||
- One-time spend public = `spend_pk + Hash(shared_secret)·G_PQ` (где G_PQ — generator в lattice space).
|
||||
- Получатель decapsulates ciphertext → shared_secret → распознаёт что транзакция для него.
|
||||
|
||||
**Ограничение:** размер one-time-address пакета ~ 1.5 КБ vs ~ 64 байт в классическом Monero.
|
||||
|
||||
### 5.3 PQ Range Proofs (amount privacy)
|
||||
|
||||
Заменяет Bulletproofs. Доказательство что сумма перевода в диапазоне [0, 2^64) без раскрытия суммы.
|
||||
|
||||
**Lattice-based zk range proofs:**
|
||||
- Esgin-Nguyen-Seiler 2020 (lattice-based zk for SIS/LWE).
|
||||
- ZKBoo / ZKB++ family (post-quantum NIZK).
|
||||
|
||||
**Параметры:**
|
||||
- Размер доказательства: 5–50 КБ в текущих research-схемах (vs ~1 КБ в Bulletproofs).
|
||||
- Время верификации: 50–200 ms (vs 5 ms Bulletproofs).
|
||||
|
||||
**Ограничение:** значительно тяжелее классических Bulletproofs. Требует оптимизации либо принятия повышенной нагрузки.
|
||||
|
||||
## 6. Транзакционная модель
|
||||
|
||||
### 6.1 Структура private TC transfer
|
||||
|
||||
```
|
||||
PrivateTransfer {
|
||||
ring_signature: LatticeRingSig, // sender privacy
|
||||
stealth_recipient: PQStealthAddress, // recipient privacy
|
||||
amount_commitment: LatticeCommitment, // amount privacy
|
||||
range_proof: PQRangeProof, // proof: 0 ≤ amount ≤ supply
|
||||
nullifier: SHA256(...), // prevent double-spend
|
||||
fee_public: TC, // комиссия публична
|
||||
τ_anchor: TimeChainPosition, // каноническая позиция
|
||||
signature: ML-DSA-65, // подпись по канону
|
||||
}
|
||||
```
|
||||
|
||||
### 6.2 Двойная трата защищена через nullifier
|
||||
|
||||
Каждый private input производит уникальный `nullifier` который публикуется в TimeChain. Узлы поддерживают глобальное множество использованных nullifier'ов. Попытка повторно потратить тот же UTXO даёт коллизию nullifier и отвергается.
|
||||
|
||||
### 6.3 Anchor в TimeChain
|
||||
|
||||
Private transaction коммитится в каноническое окно τ через якорь:
|
||||
|
||||
```
|
||||
TimeChain[τ].private_anchors = SHA256(
|
||||
ring_signature || stealth_recipient || amount_commitment ||
|
||||
range_proof || nullifier || fee_public || ...
|
||||
)
|
||||
```
|
||||
|
||||
Каноническое время гарантировано публичное. Содержимое анкера — приватное.
|
||||
|
||||
## 7. Размеры и производительность
|
||||
|
||||
| Компонент | Public Montana | Private (Монеро-Монтана) |
|
||||
|-----------|----------------|--------------------------|
|
||||
| Размер транзакции | ~5 КБ (ML-DSA-65 sig) | ~50–100 КБ (ring + stealth + range) |
|
||||
| Время подписания | ~10 мс | ~500 мс – 5 с |
|
||||
| Время верификации | ~5 мс | ~50–500 мс |
|
||||
| Транзакций в окне (τ₁=60с) | ~10⁴+ | ~10² (ограничение verifier) |
|
||||
|
||||
**Вывод:** приватный слой существенно тяжелее публичного. Это **сознательный trade-off** — приватность дорогая. В Monero аналогичные числа.
|
||||
|
||||
## 8. Защита от атак
|
||||
|
||||
### 8.1 Sybil против anonymity set
|
||||
|
||||
Атакующий мог бы подкупить операторов для смещения выбора anonymity set к подложным аккаунтам.
|
||||
|
||||
**Защита:** anonymity set выбирается псевдослучайно из VDF-выхода окна — детерминированно и нескомпрометируемо.
|
||||
|
||||
### 8.2 Timing attacks через τ-координату
|
||||
|
||||
Транзакция в окне τ привязана к публичному времени → возможно корреляционный анализ "кто был онлайн в момент публикации".
|
||||
|
||||
**Защита:** decoy delays — частный мод позволяет накапливать транзакции в локальный pool и публиковать через random-jitter в течение нескольких окон.
|
||||
|
||||
**Открытый вопрос:** формальный анализ устойчивости к traffic analysis на сетевом уровне (eclipse + observation).
|
||||
|
||||
### 8.3 Quantum attack
|
||||
|
||||
Все примитивы PQ → Шор не работает. Остаётся Гровер с квадратичным ускорением — требует увеличения хеш-длины для critical primitives.
|
||||
|
||||
## 9. Совместимость с public Monero
|
||||
|
||||
**Atomic swap** (см. [Atomic-Swap-Протокол](Atomic-Swap-Протокол.md)) — параллельная работа public Monero (XMR) и private Монеро-Монтана (TC) без моста. Пользователь обменивает XMR ↔ TC через protocol-level swap, никаких wrapped токенов, никакого central bridge.
|
||||
|
||||
## 10. Открытые исследовательские вопросы
|
||||
|
||||
- [ ] Выбор production-grade PQ ring signature schema (MatRiCT+? newer?).
|
||||
- [ ] PQ range proof оптимизация — текущие схемы тяжёлые.
|
||||
- [ ] Формальный анализ traffic-analysis устойчивости.
|
||||
- [ ] Совместимость с lightweight clients (мобильные кошельки) — приватные слои тяжелее.
|
||||
- [ ] Governance: как обновлять private layer separately от public (см. [12 Управление](../12%20Управление%20и%20Обновления/Governance.md)).
|
||||
- [ ] Cross-chain swap audit — atomic swap безопасность при византийских участниках.
|
||||
|
||||
## 11. Связанные документы
|
||||
|
||||
- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md)
|
||||
- [Постквантовые замены](Постквантовые-замены.md)
|
||||
- [Atomic Swap протокол](Atomic-Swap-Протокол.md)
|
||||
- [Дорожная карта](Дорожная-Карта.md)
|
||||
- [02 Криптография](../02%20Криптография/) — базовые PQ-примитивы Монтаны
|
||||
- [04 Спецификация протокола](../04%20Спецификация%20Протокола/) — основная спека
|
||||
|
||||
## 12. Источники
|
||||
|
||||
1. Saberhagen, N. (2013). *CryptoNote v 2.0* — основа Monero.
|
||||
2. Noether, S. (2015). *Ring Confidential Transactions*. Ledger.
|
||||
3. Bünz, B., Bootle, J., Boneh, D., Poelstra, A., Wuille, P., Maxwell, G. (2018). *Bulletproofs: Short Proofs for Confidential Transactions and More*. IEEE S&P.
|
||||
4. Esgin, M. F., Steinfeld, R., Sun, S.-F., et al. (2019). *MatRiCT: Efficient, Scalable and Post-Quantum Blockchain Confidential Transactions Protocol*. CCS.
|
||||
5. Esgin, M. F., Nguyen, N. K., Seiler, G. (2020). *Practical Exact Proofs from Lattices*. ASIACRYPT.
|
||||
6. Goodell, B., Noether, S., Blue, A. (2020). *Concise Linkable Ring Signatures and Forgery Against Adversarial Keys* (CLSAG).
|
||||
7. NIST FIPS 203, 204, 205 (2024) — PQ стандарты.
|
||||
@ -0,0 +1,107 @@
|
||||
# Вызов Монеро-сообществу
|
||||
|
||||
**Открытое письмо**
|
||||
**От:** автор Montana TimeChain (efir369999)
|
||||
**К:** Monero core team, Monero Research Lab, Monero community
|
||||
**Дата:** 2026-05-04
|
||||
**Подписано в каноне:** [TBD — будет подписано ML-DSA-65 ключом узла мос (Москва genesis) после ревью]
|
||||
|
||||
---
|
||||
|
||||
## К сообществу Monero
|
||||
|
||||
Команда Monero за более чем десятилетие работы создала единственную proven privacy infrastructure в публичном блокчейне с реальной cypherpunk культурой. RingCT, CLSAG, Bulletproofs, stealth addresses — это компоненты которые научили индустрию что приватность в денежном консенсусе **возможна**, **проверяема** и **без доверия третьим сторонам**.
|
||||
|
||||
Мы строим Montana — пост-квантовый блокчейн где базовая редкость это **время**, а не stake/hashrate. Базовый консенсус Monero и Monero нигде не пересекаются — но архитектурное решение приватного финансового слоя на нашей сети должно стоять на плечах вашей работы. Скопировать ваш код напрямую мы **не можем** (вся Montana держится на пост-квантовых примитивах FIPS 203/204; ваш Ed25519 + SECP256k1 не PQ). Но **архитектурное наследие** — ring signatures, stealth addresses, range proofs — это разработанная вами модель которую разумно адаптировать с PQ-примитивами.
|
||||
|
||||
Этот документ — публичное **приглашение к диалогу**, а не объявление о копировании.
|
||||
|
||||
## О чём именно вызов
|
||||
|
||||
Мы предлагаем три возможных пути сотрудничества; готовы обсуждать любой подмножество или альтернативы.
|
||||
|
||||
### Путь 1 — Рецензия архитектурной спецификации
|
||||
|
||||
Мы написали [техническую спецификацию приватного финансового слоя Монеро-Монтана](Архитектура.md) с пост-квантовыми заменами для каждого Monero-примитива. Просим Monero Research Lab или независимых cryptographers рецензировать:
|
||||
|
||||
- [ ] Корректность концептуальной адаптации.
|
||||
- [ ] Полноту трёх свойств приватности (sender/recipient/amount).
|
||||
- [ ] Качество выбора PQ-схем (lattice ring signatures, PQ stealth, PQ range proofs).
|
||||
- [ ] Возможные mistakes которые мы могли упустить.
|
||||
|
||||
Мы оплатим рецензию по ставкам которые предложит сторона. Бюджет ограничен (проект некоммерческий) — но за качественную обратную связь готовы найти ресурсы.
|
||||
|
||||
### Путь 2 — Atomic Swap Montana ↔ Monero
|
||||
|
||||
[Atomic Swap протокол](Atomic-Swap-Протокол.md) — interop между публичной Montana и Monero без bridge, без wrapped токенов, без посредников. Технически реализуется через адаптер на стороне обеих сетей; на Monero нужны hash-time-locked contracts (или их аналог).
|
||||
|
||||
Это путь который **выгоден обеим сторонам**:
|
||||
|
||||
- Пользователи Монеро получают мост к новой PQ сети где время — каноническая координата.
|
||||
- Пользователи Монтаны получают доступ к проверенной приватности XMR без риска bridge-hack'а.
|
||||
|
||||
Просим:
|
||||
- [ ] Совместное ревью протокола swap'а.
|
||||
- [ ] Идентификация самой удобной точки интеграции на стороне Monero (адаптер демона / wallet RPC / другое).
|
||||
- [ ] Тестирование на Monero stagenet ↔ Monero-Montana stagenet.
|
||||
|
||||
### Путь 3 — Совместный research на PQ-приватность
|
||||
|
||||
Мы видим что Monero уже думает о post-quantum миграции (research papers, дискуссии в MRL). Текущая Monero крипта классическая, но команда осознаёт что переход неизбежен.
|
||||
|
||||
**Совместный исследовательский трек:**
|
||||
|
||||
- Анализ MatRiCT/MatRiCT+ и последующих lattice ring signatures для production.
|
||||
- PQ range proof оптимизация — текущие схемы 5–50 КБ против 1 КБ Bulletproofs; это критичный gap.
|
||||
- PQ stealth addresses — производит ли ML-KEM-768 эквивалентную приватность?
|
||||
|
||||
Если Monero когда-либо мигрирует на PQ — наша спецификация может быть полезной basis или counter-example.
|
||||
|
||||
## Что мы НЕ просим
|
||||
|
||||
- ❌ **Не просим адаптировать Monero под Montana TimeChain.** Monero — самостоятельная сеть; мы хотим быть рядом, а не подменить.
|
||||
- ❌ **Не просим брендинг "Monero on Montana"** без вашего согласия. Если получится сотрудничество — назовём как договоримся.
|
||||
- ❌ **Не предлагаем wrapping XMR в Montana через мост.** Bridges — крупнейший класс уязвимостей DeFi (Wormhole $325M, Ronin $625M, Nomad $190M). Мы не делаем мост.
|
||||
- ❌ **Не просим донации, не предлагаем airdrop, не запускаем ICO/IDO.** Проект некоммерческий.
|
||||
|
||||
## Что мы предлагаем взамен
|
||||
|
||||
- ✅ **Транспарентность.** Вся спецификация Montana и Monero-Montana доступна в полном виде на `montana.quest`, без regulatory closed-source элементов.
|
||||
- ✅ **Russian + English + Chinese spec coverage.** Whitepaper в трёх языках.
|
||||
- ✅ **Internal security audit** уже сделан, доступен публично ([Internal-Audit-2026-05-04](../09%20Внешний%20Аудит/Internal-Audit-2026-05-04.md)). Внешний аудит планируется (ищем компанию).
|
||||
- ✅ **TLA+ формальная верификация** consensus в работе ([10 Формальная верификация](../10%20Формальная%20Верификация/)).
|
||||
- ✅ **Приоритет honesty над hype.** [3-pillar критика](../../Монтана-Протокол/Внешний%20аудит/critic-analysis-2026-05-04-3-pillars.md) опубликована открыто; мы не скрываем что мы pre-launch и что у нас 3 узла.
|
||||
|
||||
## Технические вопросы к вам
|
||||
|
||||
1. Какая PQ ring signature schema вам кажется наиболее жизнеспособной для production (с учётом того что вы профессионально работаете с этой математикой)?
|
||||
2. Видите ли вы конкретные ошибки в нашей PQ-адаптации stealth addresses через ML-KEM-768?
|
||||
3. Какой бы adapter point на стороне Monero вы предложили для atomic swap'а? Wallet RPC? Демон-плагин? Отдельный daemon?
|
||||
4. Если бы Monero завтра нужно было мигрировать на PQ — какой path вы бы выбрали? Bullet через timeline? Совместимый upgrade? Полная отдельная chain?
|
||||
|
||||
## Как ответить
|
||||
|
||||
- Ответ через GitHub Issues / Discussions на `montana.quest/efir369999/montana`
|
||||
- Email: efir369999@gmail.com
|
||||
- Через Monero IRC #monero-research-lab или #monero-dev — как удобно.
|
||||
- Mastodon / Nostr / любые предпочитаемые вашему сообществу каналы.
|
||||
|
||||
Готовы быть терпеливыми. Ждать ответа недели и месяцы.
|
||||
|
||||
## Важная оговорка
|
||||
|
||||
Этот вызов — **запрос диалога**, не объявление о начале работы. Мы понимаем культуру Monero: тэги ради хайпа здесь не приветствуются. Если за этим документом не последует реальное взаимодействие — мы не публикуем "Monero-Montana" без вашего согласия. Мы либо строим вместе, либо не строим под этим именем вообще.
|
||||
|
||||
Если ответ negative — мы благодарны за время и продолжаем без референса к Monero, формулируя приватный слой как "Montana Privacy Layer" без указания происхождения архитектурных идей.
|
||||
|
||||
## Подпись
|
||||
|
||||
Подписано:
|
||||
- Author: Алехандро Монтана (efir369999)
|
||||
- Account: `4c290c3d5d63e84b99c30c83fb4d172e04102af4492b4d56d0642711b09e2072`
|
||||
- Sigantura ML-DSA-65: [TBD]
|
||||
- Хеш SHA-256 этого документа: [TBD]
|
||||
|
||||
---
|
||||
|
||||
Нет приватности — нет финансовой свободы. Нет финансовой свободы — нет нации.
|
||||
@ -0,0 +1,177 @@
|
||||
# Дорожная карта Монеро-Монтана
|
||||
|
||||
**Версия:** 1.0 draft
|
||||
**Зависимости:** mainnet readiness Монтаны (G1–G3, G5 в [Mainnet-Readiness](../Mainnet-Readiness.md))
|
||||
|
||||
## Принципиальный порядок
|
||||
|
||||
```
|
||||
M9 → M10 → M11 → M12 → M13
|
||||
└──┬──┘ └─┬──┘ └──┬───┘
|
||||
public- atomic PQ-private
|
||||
launch swap layer
|
||||
```
|
||||
|
||||
Atomic swap не требует full PQ-private layer — это самостоятельный milestone после public mainnet.
|
||||
PQ-private layer — separate research track который может идти параллельно.
|
||||
|
||||
## Этапы
|
||||
|
||||
### M9 — Public mainnet (предварительная)
|
||||
|
||||
**Зависимость:** ничего из Монеро-Монтана.
|
||||
**Что должно быть закрыто:** G1–G3, G5 в [Mainnet-Readiness](../Mainnet-Readiness.md).
|
||||
**Срок:** определяется внешними факторами (внешний аудит, набор операторов).
|
||||
|
||||
После закрытия M9 публичная Montana работает в launched mainnet режиме без приватного слоя. Все переводы прозрачны как сейчас.
|
||||
|
||||
### M10 — Pre-Monero hardening
|
||||
|
||||
**Зависимость:** M9 mainnet.
|
||||
**Срок:** 2–4 недели после M9.
|
||||
|
||||
Что:
|
||||
1. Опубликовать [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) через каналы автора.
|
||||
2. Ожидание ответа Monero community (4–12 недель). Параллельно — внутренний research.
|
||||
3. Если ответ negative или отсутствует → переименовать "Монеро-Монтана" в "Montana Privacy Layer" без референса к Monero.
|
||||
4. Если ответ positive → начать совместный технический dialog.
|
||||
|
||||
### M11 — Atomic Swap Montana ↔ Monero
|
||||
|
||||
**Зависимость:** M9 mainnet, M10 communication results.
|
||||
**Срок:** 2–6 месяцев после M9.
|
||||
|
||||
Этапы внутри M11:
|
||||
|
||||
#### M11.1 — Спецификация HTLC operations
|
||||
- [ ] MIP-001 «HTLC Operations in Account Chain»
|
||||
- [ ] Спецификация типов: `HTLCLock`, `HTLCClaim`, `HTLCRefund`
|
||||
- [ ] Описание token transitions (lock → claim/refund)
|
||||
- [ ] Включение в основную спеку Montana Protocol
|
||||
|
||||
#### M11.2 — Reference implementation на Montana
|
||||
- [ ] crate `mt-htlc` с full HTLC support
|
||||
- [ ] Тесты на single-node, multi-node, partition scenarios
|
||||
- [ ] Интеграция в `montana-node`
|
||||
|
||||
#### M11.3 — Monero side adapter
|
||||
- [ ] Изучение xmr-btc-swap кодовой базы (COMIT)
|
||||
- [ ] Адаптация adaptor signature wrapper'а для Monero ↔ Montana
|
||||
- [ ] Standalone daemon `monero-montana-swapd`
|
||||
|
||||
#### M11.4 — Тестовая сеть swap
|
||||
- [ ] Тест swap'а Monero stagenet ↔ Montana stagenet
|
||||
- [ ] Многократные swaps под нагрузкой
|
||||
- [ ] Тест сценариев refund (timeout)
|
||||
- [ ] Тест сценариев partition
|
||||
|
||||
#### M11.5 — Audit + production launch
|
||||
- [ ] Внешний security audit обеих сторон
|
||||
- [ ] Bug fixes
|
||||
- [ ] Mainnet activation HTLC operations через MIP soft fork
|
||||
- [ ] Публикация инструмента для пользователей
|
||||
|
||||
### M12 — Public Monero ↔ Montana production
|
||||
|
||||
**Зависимость:** M11 завершён.
|
||||
**Срок:** 1–3 месяца после M11.
|
||||
|
||||
- Стабильная работа atomic swap.
|
||||
- Документация для пользователей.
|
||||
- Поддержка через wallets (если Monero community согласна интегрировать).
|
||||
- Мониторинг volume, latency, success rate swaps.
|
||||
|
||||
### M13 — PQ-Private Layer (research+impl track)
|
||||
|
||||
**Зависимость:** M9 mainnet (НЕ зависит от M11/M12). Может идти параллельно.
|
||||
**Срок:** 12–24 месяца параллельной работы.
|
||||
|
||||
Этапы:
|
||||
|
||||
#### M13.1 — Research consolidation
|
||||
- [ ] Окончательный выбор PQ ring signature schema (MatRiCT+ или новейшее).
|
||||
- [ ] Окончательный выбор PQ range proof schema.
|
||||
- [ ] PQ stealth address derivation корректность proof.
|
||||
- [ ] Консолидация в обновлённую [Архитектура.md](Архитектура.md).
|
||||
|
||||
#### M13.2 — Reference cryptographic library
|
||||
- [ ] Rust crate `mt-pq-privacy` с lattice ring sigs, PQ stealth, PQ range proofs.
|
||||
- [ ] Полное audited cryptographic implementation.
|
||||
- [ ] Performance optimization (target <50 КБ за private transaction).
|
||||
|
||||
#### M13.3 — Account Chain extension
|
||||
- [ ] Спецификация private mode opt-in на уровне Account.
|
||||
- [ ] Type extension: `PrivateTransfer` operation.
|
||||
- [ ] Nullifier set management.
|
||||
- [ ] Private balance reveal procedure.
|
||||
|
||||
#### M13.4 — Node implementation
|
||||
- [ ] Поддержка private operations в `montana-node`.
|
||||
- [ ] Verification performance optimization.
|
||||
- [ ] Storage оптимизация (private operations большие).
|
||||
|
||||
#### M13.5 — Тестовая сеть PQ-private
|
||||
- [ ] Запуск private layer на тестовой Montana сети.
|
||||
- [ ] Stress-тест на throughput.
|
||||
- [ ] Privacy analysis: реальная anonymity при разных anonymity set sizes.
|
||||
|
||||
#### M13.6 — Audit + production
|
||||
- [ ] Внешний audit cryptographic library.
|
||||
- [ ] Внешний audit privacy properties.
|
||||
- [ ] Mainnet activation private layer через MIP-002.
|
||||
|
||||
## Критические точки решения
|
||||
|
||||
### Решение R1 (после M10): Monero сотрудничество — Y/N?
|
||||
|
||||
| Сценарий | Ответ Monero | Действие |
|
||||
|----------|--------------|----------|
|
||||
| Positive | Сотрудничают по review/swap | Продолжаем M11 с brand "Монеро-Монтана" |
|
||||
| Neutral / нет ответа | 12+ недель тишина | Делаем M11 с brand "Montana Atomic Swap with Monero" — нейтрально |
|
||||
| Negative | "Не нужно" | Делаем atomic swap унилатерально как technical interop, без brand. M13 с brand "Montana Privacy Layer" без Monero |
|
||||
|
||||
### Решение R2 (после M11): Atomic Swap или сразу M13?
|
||||
|
||||
Если M11 успешно работает в production — можно выбирать:
|
||||
- **Опция A:** Сосредоточиться на M13 (PQ-private layer) — более амбициозно, дольше.
|
||||
- **Опция B:** Расширить M11 на другие приватные сети (Zcash atomic swap?, ETH с tornado-style?) — приватность через interop, не через native.
|
||||
|
||||
R2 решается на основе того что показал M11 (в т.ч. насколько "приватность Monero снизу" достаточна, или нужен native).
|
||||
|
||||
### Решение R3 (внутри M13): Какая PQ schema?
|
||||
|
||||
Зависит от research progress в академии за следующие 12–24 месяца. К моменту начала M13.1 нужно проверить SOTA.
|
||||
|
||||
## Бюджет и ресурсы (грубо)
|
||||
|
||||
Это некоммерческий проект; "бюджет" в смысле времени и сторонних услуг.
|
||||
|
||||
| Этап | Авторская работа (мес) | Внешние услуги |
|
||||
|------|------------------------|----------------|
|
||||
| M11 (atomic swap) | 4–6 мес | Аудит ≈ $30–80k (только если коммерческий путь возможен) |
|
||||
| M13 (PQ-private) | 12–24 мес | Аудит cryptographic library ≈ $50–150k |
|
||||
|
||||
Без внешнего бюджета на аудит:
|
||||
- Использовать internal review + Claude Opus 4.7 critics (как сейчас)
|
||||
- Использовать формальную верификацию (TLA+) для consensus и crypto reductions
|
||||
- Prioritize bullet-proof logic over external audit
|
||||
|
||||
Это снижает confidence но не блокирует production.
|
||||
|
||||
## Зависимости от внешних факторов
|
||||
|
||||
| Фактор | Влияние | Mitigation |
|
||||
|--------|---------|------------|
|
||||
| Monero community engagement | Critical для brand "Монеро-Монтана" | R1 fallback на нейтральный brand |
|
||||
| MatRiCT+ или newer SOTA в lattice ring sigs | Критично для M13 | Мониторим публикации; fallback на STARK-based |
|
||||
| External audit budget | Критично для full production confidence | Internal + formal verification как baseline |
|
||||
| Operator network growth (G3) | Критично для M9 | См. [M9-Расширение-Сети](../11%20Тестовая%20Сеть/M9-Расширение-Сети.md) |
|
||||
|
||||
## Связанные документы
|
||||
|
||||
- [README](README.md) — overview папки.
|
||||
- [Архитектура](Архитектура.md) — техническая спецификация.
|
||||
- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) — M10 deliverable.
|
||||
- [Atomic Swap протокол](Atomic-Swap-Протокол.md) — M11 deliverable.
|
||||
- [Постквантовые замены](Постквантовые-замены.md) — M13 research basis.
|
||||
- [Mainnet-Readiness](../Mainnet-Readiness.md) — M9 предварительная зависимость.
|
||||
@ -0,0 +1,198 @@
|
||||
# Постквантовые замены Monero-примитивов
|
||||
|
||||
**Версия:** 1.0 draft
|
||||
**Цель:** для каждого ключевого Monero-примитива — конкретная PQ-замена с обоснованием выбора и known-tradeoffs.
|
||||
|
||||
## Сводная таблица
|
||||
|
||||
| Monero (классический) | PQ-замена в Монеро-Монтане | Источник | Готовность |
|
||||
|------------------------|----------------------------|----------|------------|
|
||||
| CLSAG ring signature (Ed25519) | Lattice ring signature (MatRiCT+ или новейшая) | Esgin-Steinfeld-Sun 2019, MatRiCT+ 2022 | Research, не production |
|
||||
| Stealth addresses (curve25519 DH) | PQ stealth via ML-KEM-768 KEM | NIST FIPS 203 | Готов, нужна формализация derivation |
|
||||
| Pedersen commitment + Bulletproofs (SECP) | Lattice commitment + Lattice range proof | Esgin-Nguyen-Seiler 2020, Lyubashevsky-Nguyen-Plançon 2022 | Research, тяжёлая |
|
||||
| Triptych anonymity (next-gen) | Lattice-based аналог | Не существует production-ready | TBD |
|
||||
| EdDSA (transaction signatures) | ML-DSA-65 (FIPS 204) | NIST 2024 | Production-ready |
|
||||
| SHA-3 (some hashes) | SHA-256 (consistent с TimeChain) | NIST FIPS 180-4 | Production-ready |
|
||||
|
||||
## 1. Ring Signature: CLSAG → Lattice Ring Signature
|
||||
|
||||
### Что делает CLSAG в Monero
|
||||
|
||||
Подписант доказывает что он один из K=11 потенциальных подписантов из anonymity set без раскрытия конкретного. Использует Ed25519 + Schnorr-подобную конструкцию + linkability tag для предотвращения двойного подписания.
|
||||
|
||||
### Почему нужна замена
|
||||
|
||||
Ed25519 базируется на эллиптической кривой (curve25519). Алгоритм Шора ломает дискретный логарифм за полиномиальное время → ring signature становится тривиально проследимой при появлении достаточно мощного квантового компьютера.
|
||||
|
||||
### MatRiCT+ как кандидат
|
||||
|
||||
Esgin et al. (2022) предложили improved version их 2019-й работы. Параметры:
|
||||
|
||||
- Категория безопасности: NIST L3 (≥192 бит классических, ≥128 квантовых).
|
||||
- Размер подписи: ~5–20 КБ (в зависимости от K). Bigger чем Monero CLSAG ~0.5 КБ, но в пределах разумного.
|
||||
- Время подписания: ~100–500 мс на современном CPU.
|
||||
- Время верификации: ~50–200 мс.
|
||||
|
||||
### Альтернативы
|
||||
|
||||
- **Mubarak-Shen 2024** и другие более поздние lattice ring signatures — могут быть лучше по размеру, но менее проверены.
|
||||
- **One-out-of-many SNARK** — теоретически возможно, но требует trusted setup или post-quantum SNARK с большим overhead.
|
||||
|
||||
### Решение
|
||||
|
||||
Использовать MatRiCT+ как baseline, мониторить новые публикации каждые 6 месяцев. Если появится production-grade implementation с лучшими параметрами — мигрировать через MIP в [12 Управление](../12%20Управление%20и%20Обновления/).
|
||||
|
||||
### Открытые вопросы
|
||||
|
||||
- Готовая audited implementation на Rust? Нет. Нужен либо port from C++ research code, либо самостоятельная реализация. Это значимый риск (см. F-01 в [Internal Audit](../09%20Внешний%20Аудит/Internal-Audit-2026-05-04.md)).
|
||||
- Совместимость с lightweight clients (мобильные кошельки)? Требует оптимизации.
|
||||
|
||||
## 2. Stealth Addresses: curve25519 DH → ML-KEM-768
|
||||
|
||||
### Что делают stealth addresses в Monero
|
||||
|
||||
Получатель публикует одну пару ключей (view, spend). Отправитель генерирует one-time public key для конкретной транзакции через DH-протокол:
|
||||
|
||||
```
|
||||
r = random scalar
|
||||
R = r·G (опубликовано в transaction)
|
||||
P = Hash(r·V)·G + S (target one-time address)
|
||||
```
|
||||
|
||||
Получатель сканирует транзакции, проверяет принадлежность через свой view-secret-key.
|
||||
|
||||
### PQ адаптация через ML-KEM-768
|
||||
|
||||
Заменяем DH на key encapsulation:
|
||||
|
||||
```
|
||||
(view_pk, view_sk) ← ML-KEM-768 keygen()
|
||||
(spend_pk, spend_sk) ← ML-DSA-65 keygen()
|
||||
|
||||
Sender:
|
||||
(ct, K) ← ML-KEM-768 encapsulate(view_pk)
|
||||
one_time_addr = spend_pk + Hash(K)·G_PQ # G_PQ — generator в lattice space
|
||||
Publish (one_time_addr, ct) on chain.
|
||||
|
||||
Recipient (scan):
|
||||
K' ← ML-KEM-768 decapsulate(view_sk, ct)
|
||||
expected = spend_pk + Hash(K')·G_PQ
|
||||
if expected == one_time_addr: this transaction is mine.
|
||||
```
|
||||
|
||||
### Параметры
|
||||
|
||||
- ML-KEM-768 ciphertext: 1088 байт.
|
||||
- ML-KEM-768 public key: 1184 байт.
|
||||
- Размер one-time-address packet: ~1.5 КБ vs ~64 байт классический Monero.
|
||||
|
||||
### Открытые вопросы
|
||||
|
||||
- Корректность derivation `spend_pk + Hash(K)·G_PQ` в lattice space — нужна формальная проверка что this preserves ML-DSA-65 EUF-CMA.
|
||||
- Sub-address scheme (Monero supports multiple stealth addresses from one base) — нужна PQ-адаптация.
|
||||
|
||||
## 3. Range Proofs: Bulletproofs → Lattice Range Proofs
|
||||
|
||||
### Что делают Bulletproofs в Monero
|
||||
|
||||
Доказательство `0 ≤ amount < 2^64` без раскрытия amount. Использует Pedersen commitments + inner-product argument на эллиптической кривой.
|
||||
|
||||
Параметры Monero (post-2018):
|
||||
- Размер: ~675 байт для одного output.
|
||||
- Время верификации: ~5 мс.
|
||||
|
||||
### PQ замены
|
||||
|
||||
#### 3.1 Esgin-Nguyen-Seiler 2020
|
||||
|
||||
Lattice-based exact proofs через amortized SIS protocol.
|
||||
|
||||
- Размер: ~5–15 КБ за range proof.
|
||||
- Время верификации: ~50–100 мс.
|
||||
|
||||
#### 3.2 Lyubashevsky-Nguyen-Plançon 2022
|
||||
|
||||
Improvement предыдущих lattice proofs.
|
||||
|
||||
- Размер: ~3–10 КБ.
|
||||
- Время верификации: ~30–80 мс.
|
||||
|
||||
#### 3.3 SNARK-based PQ (e.g. STARK)
|
||||
|
||||
STARKs пост-квантовы по построению (hash-based).
|
||||
|
||||
- Размер: ~50–200 КБ (большой!).
|
||||
- Время верификации: ~5–20 мс (очень быстро благодаря logarithmic).
|
||||
- Trusted setup: НЕ нужен (это плюс).
|
||||
|
||||
### Решение
|
||||
|
||||
Lyubashevsky-Nguyen-Plançon как baseline. STARKs как fallback если lattice не reach acceptable size.
|
||||
|
||||
### Trade-off
|
||||
|
||||
PQ range proofs **значительно тяжелее** Bulletproofs:
|
||||
- Размер: 3–10× больше.
|
||||
- Verifier time: 6–20× больше.
|
||||
|
||||
Это означает что throughput приватного слоя меньше public Montana. Это **сознательное** решение — приватность стоит производительности.
|
||||
|
||||
## 4. Подписи: Ed25519 → ML-DSA-65
|
||||
|
||||
Уже решено в основной спецификации Монтаны. ML-DSA-65 (FIPS 204) — production-ready.
|
||||
|
||||
| Параметр | Ed25519 | ML-DSA-65 |
|
||||
|----------|---------|-----------|
|
||||
| Public key | 32 байт | 1952 байт |
|
||||
| Подпись | 64 байт | 3309 байт |
|
||||
| Уровень безопасности | 128 бит классических, **0 квантовых** | 192 классических, 128 квантовых |
|
||||
|
||||
## 5. Хеш-функции
|
||||
|
||||
Унификация: SHA-256 везде где это разумно. Monero использует Keccak; Montana использует SHA-256 (соответствует FIPS 180-4 и используется в VDF). При интеграции на boundary — convertor.
|
||||
|
||||
## 6. Сводный анализ trade-off
|
||||
|
||||
```
|
||||
Размер транзакции:
|
||||
Public Monero: ~2–3 КБ
|
||||
Public Montana: ~5 КБ
|
||||
Монеро-Монтана: ~50–100 КБ (10–20× public Montana)
|
||||
|
||||
Время верификации одной транзакции:
|
||||
Public Monero: ~10 мс
|
||||
Public Montana: ~5 мс
|
||||
Монеро-Монтана: ~100–500 мс (20–100× public Montana)
|
||||
|
||||
Throughput транзакций в окне τ₁=60с:
|
||||
Public Monero: ~10⁴+ tx/блок
|
||||
Public Montana: ~10⁴+ tx/окно
|
||||
Монеро-Монтана: ~100 tx/окно (consensus bottleneck — verification time)
|
||||
```
|
||||
|
||||
**Это значит:** приватный слой имеет существенно меньшую пропускную способность чем публичный. Это **honest trade-off** — приватность дорогая.
|
||||
|
||||
## 7. Открытые направления исследований
|
||||
|
||||
- [ ] Bench MatRiCT+ vs newer schemes — какая лучше для Монтаны.
|
||||
- [ ] Реальная implementation хотя бы reference в Rust (нет готовых сейчас).
|
||||
- [ ] Audited cryptographic library с PQ ring sigs (нет в open-source проектах).
|
||||
- [ ] Optimization range proofs: targeting <5 КБ.
|
||||
- [ ] Compatibility с mobile/lightweight clients.
|
||||
|
||||
## 8. Связанные документы
|
||||
|
||||
- [Архитектура](Архитектура.md) — где эти примитивы используются.
|
||||
- [02 Криптография](../02%20Криптография/) — базовые PQ-примитивы Монтаны.
|
||||
- [09 Внешний аудит](../09%20Внешний%20Аудит/) — F-01 single-implementation risk применим к этим примитивам тоже.
|
||||
- [Вызов Монеро-сообществу](Вызов-Монеро-сообществу.md) — приглашение к рецензии этих choices.
|
||||
|
||||
## 9. Источники
|
||||
|
||||
1. Esgin, M. F., Steinfeld, R., Sun, S.-F., et al. (2019). *MatRiCT*. CCS.
|
||||
2. Esgin, M. F., et al. (2022). *MatRiCT+*. (newer revision).
|
||||
3. Esgin, M. F., Nguyen, N. K., Seiler, G. (2020). *Practical Exact Proofs from Lattices*. ASIACRYPT.
|
||||
4. Lyubashevsky, V., Nguyen, N. K., Plançon, M. (2022). *Lattice-Based Zero-Knowledge Proofs and Applications*. EUROCRYPT.
|
||||
5. Bünz, B., et al. (2018). *Bulletproofs*. IEEE S&P. (для контекста сравнения)
|
||||
6. Goodell, B., Noether, S., Blue, A. (2020). *CLSAG*. (для контекста сравнения)
|
||||
7. Ben-Sasson, E., et al. (2018). *Scalable, transparent, and post-quantum secure computational integrity* (STARK).
|
||||
Loading…
Reference in New Issue
Block a user