92 lines
8.0 KiB
Markdown
92 lines
8.0 KiB
Markdown
# Proof of Time (PoT) — консенсус Монтаны
|
||
|
||
**Версия:** черновик 1.0
|
||
**Базовый источник:** [Montana Protocol v35.25.0 §Консенсус](../../Монтана-Протокол/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%20Криптография/)).
|
||
|
||
## 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%20Формальная%20Верификация/).
|
||
- [ ] Точный анализ деградации liveness в условиях асинхронности до GST.
|
||
- [ ] Анализ устойчивости к eclipse-атаке на отдельный узел (см. [07 Модель угроз](../07%20Модель%20Угроз/)).
|
||
- [ ] Численное подтверждение 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).
|