montana/Formal-Docs/01-Consensus/Proof-of-Time.md

# Proof of Time (PoT) — консенсус Монтаны

**Версия:** черновик 1.0
**Базовый источник:** [Montana Protocol v35.25.0 §Консенсус](../../Montana-Protocol/Montana%20Protocol%20v35.25.0.md)

## 1. Сетевая модель

- **Тип сети:** частично синхронная (partially synchronous, Dwork-Lynch-Stockmeyer 1988). После неизвестного времени GST сообщения доставляются в пределах Δ.
- **Канонический шаг времени:** окно τ₁ ≈ 60 секунд, генерируется верифицируемой функцией задержки (VDF) над SHA-256, D итераций последовательно (D₀ = 325 000 000).
- **Адаптация:** D пересчитывается каждые τ₂ = 20 160 окон (≈ 14 дней) по медианному наблюдаемому времени окна у честных операторов.
- **Глобальная координата:** длина VDF-цепи равна протекшему настенному времени с генезиса. Восстанавливается любым проверяющим без доверенной установки.

## 2. Модель противника

- **Византийский противник** в смысле Lamport-Shostak-Pease 1982: f узлов из n могут отклоняться произвольно (включая сговор и неверные сообщения).
- **Допущение по доле:** безопасность сохраняется при f < n/3 (стандартный BFT-порог для частичной синхронности; Castro-Liskov 1999).
- **Вычислительная модель:** противник может иметь до 100× больше параллельных вычислителей, чем честный оператор. Это **не** даёт ему 100× времени — VDF не параллелится.
- **Квантовый противник:** все классические подписи и KEM защищены постквантовыми примитивами (см. [02 Криптография](../02-Cryptography/)).

## 3. Допущения

| Допущение | Обоснование |
|-----------|-------------|
| VDF над SHA-256 несжимаем | Pietrzak 2018, Boneh-Bonneau-Bünz-Fisch 2018 — последовательность SHA-256 невозможно ускорить параллельно при D итерациях. |
| ML-DSA-65 EUF-CMA | NIST FIPS 204 (2024). Существуют классические и квантовые редукции к Module-LWE/SIS. |
| SHA-256 collision resistance | NIST FIPS 180-4. Запас безопасности ≥ 128 бит до 2040 (см. NIST SP 800-131A). |
| Канал между честными узлами | После GST доставка ≤ Δ. До GST безопасность сохраняется, liveness — нет. |

## 4. Свойства консенсуса

### 4.1 Safety (невозможность форков)

**Теорема S1.** *При f < n/3 и любой задержке сети две конфликтующие операции одного аккаунта не могут попасть в канон одновременно.*

Доказательство опирается на три независимых ограничения:
1. Один шаг на личность за окно (одношаговое правило).
2. Длина собственной AccountChain как монотонная функция.
3. Старшинство (seniority) — критерий разрешения tie-break.

Конфликтные операции попадают в разные окна или в одно — но в одно окно проходит ровно одна по детерминированному правилу лотереи.

### 4.2 Liveness

**Теорема L1.** *После GST и при f < n/3 любая корректная операция честного узла включается в канон в пределах O(Δ) после публикации.*

Liveness обеспечивается VDF-двигателем: цепь продвигается даже если только один честный оператор крутит VDF. Защита от спама — временна́я (одно окно — один шаг), не комиссионная.

## 5. Лотерея и победитель окна

Каждое окно τ₁ имеет один эпизод "VDF Reveal":
1. После запечатывания окна выход VDF становится семенем лотереи.
2. Узлы, имевшие право на участие (NodeChain актуальна, AccountChain не пуста), участвуют в детерминированном выборе.
3. Победитель τ₁ записывает якорь (Anchor) в каноническую координату.

Ключевое свойство: лотерея **single-class**, winner — всегда узел. Не плутократическая (не зависит от баланса), не PoW-затратная (не требует ASIC). См. §"Три первоэлемента протокола" в основной спецификации.

## 6. Граница применимости

| Условие | Поведение PoT |
|---------|---------------|
| f < n/3 + после GST | Safety + Liveness |
| f < n/3 + до GST | Safety, Liveness может задерживаться |
| f ≥ n/3 | Стандартный BFT-провал; PoT не претендует на безопасность за этой границей |
| Все операторы офлайн одновременно | VDF останавливается; цепь возобновляется на той же τ-координате когда хотя бы один оператор возвращается |

## 7. Сравнение с известными протоколами

| Протокол | Базовая редкость | Финальность | Квантум |
|----------|------------------|-------------|---------|
| Bitcoin (Nakamoto) | Хеш-мощность | Вероятностная | ❌ ECDSA |
| Tendermint / HotStuff | Стейк | Мгновенная | ❌ Ed25519 |
| Ouroboros | Стейк + слот | Вероятностная (settle) | Зависит |
| Solana (PoH+PoS) | Стейк + история | Вероятностная | ❌ Ed25519 |
| **Montana PoT** | **Время (VDF)** | **τ₁-окно** | ✅ ML-DSA-65 |

## 8. Открытые вопросы

- [ ] Формальное доказательство Safety в TLA+ или Coq — см. [10 Формальная верификация](../10-Formal-Verification/).
- [ ] Точный анализ деградации liveness в условиях асинхронности до GST.
- [ ] Анализ устойчивости к eclipse-атаке на отдельный узел (см. [07 Модель угроз](../07-Threat-Model/)).
- [ ] Численное подтверждение D₀ на разных x86_64 платформах через тестовую сеть.

## 9. Источники

1. Pietrzak, K. (2018). *Simple Verifiable Delay Functions*. ITCS.
2. Boneh, D., Bonneau, J., Bünz, B., Fisch, B. (2018). *Verifiable Delay Functions*. CRYPTO.
3. Dwork, C., Lynch, N., Stockmeyer, L. (1988). *Consensus in the presence of partial synchrony*. JACM.
4. Castro, M., Liskov, B. (1999). *Practical Byzantine Fault Tolerance*. OSDI.
5. NIST FIPS 204 (2024). *Module-Lattice-Based Digital Signature Standard*.
6. Lamport, L., Shostak, R., Pease, M. (1982). *The Byzantine Generals Problem*. TOPLAS.
7. Buchman, E., Kwon, J., Milosevic, Z. (2018). *The latest gossip on BFT consensus* (Tendermint).