| CLSAG ring signature (Ed25519) | Lattice ring signature (MatRiCT+ или новейшая) | Esgin-Steinfeld-Sun 2019, MatRiCT+ 2022 | Research, не production |
| 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-й работы. Параметры:
Использовать MatRiCT+ как baseline, мониторить новые публикации каждые 6 месяцев. Если появится production-grade implementation с лучшими параметрами — мигрировать через MIP в [12 Управление](../12-Governance-Updates/).
- Готовая audited implementation на Rust? Нет. Нужен либо port from C++ research code, либо самостоятельная реализация. Это значимый риск (см. F-01 в [Internal Audit](../09-External-Audit/Internal-Audit-2026-05-04.md)).
Получатель публикует одну пару ключей (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)
