2696 lines
205 KiB
Markdown
2696 lines
205 KiB
Markdown
# Montana — Спецификация протокола
|
||
|
||
**Версия:** 24.5.0 (2026-04-10 UTC)
|
||
|
||
## Определение
|
||
|
||
Montana — цифровой стандарт времени. Сеть независимых VDF-осцилляторов, поддерживающих единую верифицируемую временную шкалу с криптографическим доказательством каждого момента. Каждая зарегистрированная секунда = 1 TimeCoin (Ɉ).
|
||
|
||
NTP говорит «сейчас 14:32» — и ты доверяешь серверу. Montana говорит «сейчас 14:32, вот криптографическое доказательство, и вот что произошло в этот момент» — и ты проверяешь сам.
|
||
|
||
Основная функция — хронометраж. Вторичная — передача ценности.
|
||
|
||
Консенсус: **Proof of Time (PoT)** — четыре цепочки. TimeChain: глобальные часы (D последовательных SHA-256 = одно окно). NodeChain: персональная цепочка узла (доказательство присутствия при каждом тике). AccountChain: счётчик окон активности аккаунта. AccountTable: состояние счёта. Влияние узла = длина его NodeChain. Протокол не использует время для консенсуса — протокол и есть ход времени, оцифрованный и криптографически верифицируемый.
|
||
|
||
Генезис: 09.01.2026 00:00:00 UTC.
|
||
|
||
Генезис-фраза: `«Кто контролирует прошлое, контролирует будущее. Кто контролирует настоящее, контролирует прошлое.» — Оруэлл, 1984`
|
||
|
||
Протокол не имеет on-chain governance. Эволюция протокола проходит через Bitcoin-style процесс: открытые предложения (MIPs — Montana Improvement Proposals) публикуются в Content Layer как рекомендации, реализации выпускают новые версии, операторы узлов выбирают какую версию запускать. Fork resolution детерминирован через chain_length большинство. См. раздел «Эволюция протокола».
|
||
|
||
---
|
||
|
||
## Четыре решённые проблемы
|
||
|
||
### 1. Децентрализованный хронометраж
|
||
|
||
**Проблема.** Существующие системы измерения времени (NTP, GPS, PTP) зависят от доверенной инфраструктуры. Компрометация сервера NTP или отключение спутника GPS нарушает временную шкалу для всех зависимых систем.
|
||
|
||
**Решение.** Децентрализованные часы — сеть независимых VDF-осцилляторов, в которой каждый узел вычисляет ход времени автономно через последовательное SHA-256 хэширование. Результат детерминирован и верифицируем любым участником без доверия к третьей стороне.
|
||
|
||
**Свойства.** Montana Time обладает четырьмя свойствами одновременно:
|
||
|
||
| Свойство | Определение | NTP | GPS | PTP | Montana |
|
||
|----------|------------|-----|-----|-----|---------|
|
||
| Монотонность | Время не идёт назад | нет | да | да | да |
|
||
| Консистентность | Все честные узлы согласны на одну шкалу | слабая | да | да | да |
|
||
| Верифицируемость | Любой может доказать прохождение интервала | нет | нет | нет | да |
|
||
| Независимость | Отсутствие серверов, спутников, доверенной инфраструктуры | нет | нет | нет | да |
|
||
|
||
Ни одна существующая система измерения времени не обеспечивает все четыре свойства.
|
||
|
||
### 2. Неплутократический консенсус
|
||
|
||
**Проблема.** В Proof of Work влияние пропорционально вычислительному бюджету. В Proof of Stake — капиталу. В обоих случаях безопасность сети является функцией концентрации ресурсов, приобретаемых на рынке.
|
||
|
||
**Решение.** Proof of Time — механизм консенсуса, в котором влияние узла определяется исключительно длительностью его непрерывного присутствия в сети, измеренной в подписанных временных окнах. Вес узла = длина его NodeChain (количество окон, в которых узел криптографически доказал своё присутствие).
|
||
|
||
**Свойства.**
|
||
|
||
- Время — единственный ресурс, который нельзя приобрести, передать, делегировать или сконцентрировать
|
||
- Два участника, запустившие узлы одновременно, имеют равный вес независимо от капитала
|
||
- Стоимость атаки на консенсус выражается не в валюте, а во времени, и растёт линейно с возрастом сети
|
||
|
||
### 3. Хронометрическая эмиссия
|
||
|
||
**Проблема.** Денежная политика фиатных валют определяется решениями комитетов и непредсказуема. Денежная политика Bitcoin предсказуема, но дефляционна — фиксированный потолок supply создаёт ожидание роста цены и подавляет использование как средства обмена.
|
||
|
||
**Решение.** Хронометрическая эмиссия — денежная политика, в которой скорость создания новых единиц привязана к физической константе — секунде — и неизменна на всём горизонте существования протокола. Одна секунда протокольного времени порождает одну монету.
|
||
|
||
**Свойства.**
|
||
|
||
- Supply в момент T = количество секунд, прошедших с генезиса
|
||
- Годовая инфляция монотонно убывает и асимптотически стремится к нулю как следствие арифметики, не изменения правил
|
||
- Эмиссия не контролируется ни одним участником, комитетом или голосованием
|
||
- Денежная политика полностью определена единственной константой и не может быть изменена после генезиса
|
||
|
||
### 4. Эволюция без on-chain governance
|
||
|
||
**Проблема.** On-chain governance — голосования, советы, формальные процедуры изменения правил внутри протокола — вводит subjective компоненты в consensus state и создаёт постоянную атакуемую поверхность. Любая структура которая голосует становится мишенью: компрометация моделей, подкуп участников, юрисдикционное давление. Чем формальнее governance, тем чётче определена цель атаки.
|
||
|
||
**Решение.** Bitcoin-style эволюция. Протокол не имеет on-chain governance вообще. Изменения протокола публикуются как открытые предложения (MIPs — Montana Improvement Proposals) в Content Layer. Реализации (узловое ПО) выпускают новые версии с реализованными MIPs. Операторы узлов сами выбирают какую версию запускать. Fork resolution полностью детерминирован: при расхождении правил сеть разделяется на цепочки, каждая со своим chain_length, и узлы следуют за той цепочкой которая длиннее по их собственным правилам валидации. Никаких голосований внутри консенсуса. Никаких советов с правом подписи изменений. Никаких полей governance в state.
|
||
|
||
**Свойства.**
|
||
|
||
- Consensus state не содержит ни одного subjective поля связанного с governance — нет attack surface
|
||
- Последнее слово реально у узлов: оператор каждого узла самостоятельно решает что запускать, без посредников
|
||
- MIPs существуют как тексты в Content Layer (anchor + контент), любой может опубликовать, любой может верифицировать авторство и timestamp
|
||
- Экспертные советы (AI Council, Core Council) допустимы как **advisory** — публикуют рекомендации, обзоры, анализ безопасности; их подписи не имеют binding эффекта на consensus
|
||
- Захват advisory совета не даёт контроля над протоколом — он даёт только возможность опубликовать рекомендацию, которую узлы могут проигнорировать
|
||
- История эволюции навсегда в Content Layer через anchor — каждый MIP и каждое обсуждение timestamped в TimeChain
|
||
|
||
### Следствие: цифровой стандарт времени без человека-посредника
|
||
|
||
Четыре решённые проблемы порождают уникальную возможность. Любой документ, событие, состояние может быть записано в Montana с математически доказуемой привязкой к моменту верифицируемого времени. Anchor — 32 байта, навсегда. Ни одна существующая система не предоставляет timestamp, который одновременно децентрализован, неплутократичен, привязан к детерминированной денежной политике и свободен от on-chain governance. Montana — не блокчейн с функцией timestamping. Montana — цифровой стандарт времени с функцией передачи ценности.
|
||
|
||
Bitcoin убрал доверие к деньгам — Montana следует тому же принципу для всех слоёв. Ни один человек не может в одиночку изменить протокол. Ни одна группа разработчиков. Ни одна корпорация. Ни один совет. Изменения существуют только как открытые предложения и реализации, которые операторы узлов выбирают запускать или нет.
|
||
|
||
---
|
||
|
||
## Montana Time
|
||
|
||
VDF — цифровой аналог физического осциллятора. 9 192 631 770 колебаний цезия-133 = одна секунда SI. D последовательных SHA-256 = одно окно τ₁ Montana. Калибровка D каждые τ₂ — синхронизация цифрового осциллятора с физическим временем.
|
||
|
||
TimeChain — глобальные цифровые часы, поддерживаемые сетью узлов. Каждый узел тикает независимо через последовательное хэширование. Результат детерминирован — одни входные данные дают одну временную шкалу.
|
||
|
||
Токен — не награда за работу. Токен — тик часов, записанный в цепочку. Протокол не генерирует монеты — протокол регистрирует прошедшие секунды. Запись называется монетой.
|
||
|
||
### Четыре свойства
|
||
|
||
| Свойство | NTP | GPS | PTP | Montana |
|
||
|----------|-----|-----|-----|---------|
|
||
| Монотонность | нет | да | да | да |
|
||
| Консистентность | слабая | да | да | да |
|
||
| Верифицируемость | нет | нет | нет | да |
|
||
| Независимость | нет | нет | нет | да |
|
||
|
||
**Монотонность.** Время никогда не идёт назад. VDF последователен — каждый хэш зависит от предыдущего.
|
||
|
||
**Консистентность.** Все честные узлы согласны на одну временную шкалу. TimeChain детерминирован.
|
||
|
||
**Верифицируемость.** Любой может пересчитать VDF и доказать что заявленное время прошло.
|
||
|
||
**Независимость.** Каждый узел тикает сам. Нет серверов, спутников, доверенной инфраструктуры.
|
||
|
||
Montana — не эталон точности. Montana — эталон независимости.
|
||
|
||
### Точность
|
||
|
||
Гранулярность осциллятора: одно SHA-256 хэширование (зависит от аппаратуры: наносекунды — десятки наносекунд). Дрифт между калибровками (τ₂): единицы секунд за 14 дней. Калибровка D возвращает окно к целевым 60 секундам. Протокол самокорректируется.
|
||
|
||
### Time Oracle
|
||
|
||
TimeChain value в каждом proposal — верифицируемая временная метка. Внешние системы используют Montana Time:
|
||
|
||
- **Timestamping.** H(document) привязанный к TimeChain value = криптографическое доказательство существования в момент T.
|
||
- **Ordering.** Два события привязанные к разным TimeChain values имеют доказуемый порядок.
|
||
- **Anchoring.** Внешний протокол якорится в Montana Time для независимой верификации порядка событий.
|
||
|
||
### Протокольная дата
|
||
|
||
```
|
||
protocol_date(window_index) = genesis_timestamp + (window_index + 1) × 60
|
||
```
|
||
|
||
Genesis: 09.01.2026 00:00:00 UTC (Unix: 1 736 380 800). Proposal `window_index = 525 599` = ровно один год после генезиса. Калибровка D корректирует дрифт — протокольная дата отклоняется от UTC на единицы секунд за τ₂. Формула точна для любого window_index.
|
||
|
||
TimeChain хранится навсегда. Временные метки верифицируемы любым узлом в любой момент.
|
||
|
||
---
|
||
|
||
## Криптография
|
||
|
||
Два примитива с разделёнными ролями:
|
||
|
||
- **SHA-256** — консенсус (TimeChain, NodeChain), адреса, Merkle-деревья, хэширование
|
||
- **FN-DSA-512** (Falcon-512, выбран в финальном раунде NIST PQC selection, июль 2022; forthcoming FIPS 206; reference implementation production-ready) — подписи операций аккаунтов и proposals узлов
|
||
|
||
SHA-256 обеспечивает квантовую устойчивость консенсуса: алгоритм Гровера сокращает безопасность с 256 до 128 бит. FN-DSA-512 обеспечивает математическую постквантовую устойчивость подписей на основе NTRU-решёток. Других криптографических примитивов в протоколе нет — финансовый слой публичен, приватность данных обеспечивается на уровне приложений через Anchor.
|
||
|
||
### Подписи — FN-DSA-512
|
||
|
||
Подпись на NTRU-решётках (Falcon-512). Stateless, многоразовая. Публичный ключ закрепляется за аккаунтом при создании и используется для всех последующих операций.
|
||
|
||
| Компонент | Размер |
|
||
|-----------|--------|
|
||
| Приватный ключ | 1 281B |
|
||
| Публичный ключ | 897B |
|
||
| Подпись (padded) | 666B |
|
||
|
||
Поле suite_id в формате блока обеспечивает миграцию подписи без изменения модели состояния. Активация новой схемы требует protocol upgrade. Активная схема на момент запуска: FN-DSA-512.
|
||
|
||
### Адреса
|
||
|
||
Формат: `mt` + Base58(account_id + checksum).
|
||
|
||
Account_id = SHA-256("mt-account" || suite_id || pubkey). Стабильный идентификатор аккаунта. Смена ключа или схемы подписи выполняется через ChangeKey без изменения account_id — account_id привязан к первому pubkey, а текущий ключ хранится в состоянии аккаунта.
|
||
|
||
**Инвариант derivation.** Проверка `account_id == SHA-256("mt-account" || suite_id || pubkey)` происходит **один раз** при settle OpenAccount (apply at window close). После этого account_id — каноничный ключ записи, формула не пересчитывается. Доказательство derivation навсегда сохранено в proposal с финализированным OpenAccount. Любой аудитор может replay из proposal history. Original_pubkey не дублируется в Account Table — integrity гарантируется неизменностью proposal chain.
|
||
|
||
Поле `suite_id` в Account Table — **current** (мутируется ChangeKey синхронно с current_pubkey), используется для верификации текущих подписей. Original suite_id зафиксирован только в исторической OpenAccount записи в proposal chain.
|
||
|
||
---
|
||
|
||
## Account Chain (Block Lattice)
|
||
|
||
Каждый аккаунт имеет собственную цепочку операций. Перевод — одна операция в цепочке отправителя. Зачисление получателю — детерминированно после финализации. Цепочки аккаунтов полностью независимы.
|
||
|
||
### Реестр типов объектов
|
||
|
||
```
|
||
UserObjects:
|
||
0x01 OpenAccount
|
||
0x02 Transfer
|
||
0x03 ChangeKey
|
||
0x04 Anchor
|
||
|
||
ControlObjects:
|
||
0x10 NodeInvitation
|
||
0x11 NodeRegistration
|
||
```
|
||
|
||
### Типы операций
|
||
|
||
**Универсальная форма операции:**
|
||
|
||
```
|
||
type (1B) | prev_hash (32B) | payload (variable) | signature (666B)
|
||
```
|
||
|
||
Все операции — этот шаблон. `prev_hash` связывает операции в цепочку аккаунта. `signature` — FN-DSA-512 владельца. `payload` зависит от типа. Все non-OpenAccount операции начинают payload с `sender (32B account_id)` — узел проверяет `Account Table[sender].frontier_hash == prev_hash` и `signature валиден для current_pubkey` за O(1).
|
||
|
||
**OpenAccount** — создание аккаунта (один раз). Единственная операция где `prev_hash = 0x00...00`:
|
||
|
||
```
|
||
type 1B <- 0x01 OpenAccount
|
||
prev_hash 32B <- 0x00...00
|
||
payload 899B <- suite_id (2B) || pubkey (897B FN-DSA-512)
|
||
signature 666B
|
||
Итого: ~1 598 B
|
||
```
|
||
|
||
`account_id = SHA-256("mt-account" || suite_id || pubkey)` — детерминирован, не хранится в payload.
|
||
|
||
**Transfer** — публичный перевод:
|
||
|
||
```
|
||
type 1B <- 0x02 Transfer
|
||
prev_hash 32B
|
||
payload 80B <- sender (32B) || link (32B receiver) || amount (16B u128 nɈ)
|
||
signature 666B
|
||
Итого: ~779 B
|
||
```
|
||
|
||
`sender` — account_id отправителя, явно. Узел проверяет `Account Table[sender].frontier_hash == prev_hash` за O(1).
|
||
|
||
Открытые поля: отправитель (через frontier index по prev_hash), получатель, сумма, баланс после операции (через Account Table). Псевдонимность на уровне account_id, как Bitcoin. Финансовая приватность — задача приложений (микшеры, payment channels), не протокола.
|
||
|
||
**ChangeKey** — смена ключа или схемы подписи:
|
||
|
||
```
|
||
type 1B <- 0x03 ChangeKey
|
||
prev_hash 32B
|
||
payload 931B <- sender (32B) || new_suite_id (2B) || new_pubkey (897B)
|
||
signature 666B <- подписано старым ключом
|
||
Итого: ~1 630 B
|
||
```
|
||
|
||
**Anchor** — криптографический якорь (привязка данных ко времени):
|
||
|
||
```
|
||
type 1B <- 0x04 Anchor
|
||
prev_hash 32B
|
||
payload 96B <- sender (32B) || app_id (32B) || data_hash (32B)
|
||
signature 666B
|
||
Итого: ~795 B
|
||
```
|
||
|
||
Anchor не перемещает средства и не требует комиссии. Единственная операция — запись data_hash в цепочку аккаунта с привязкой к timechain_value окна финализации. Приватность данных приложения обеспечивается тем что в сеть попадает только хэш — содержимое хранится у владельца зашифрованным.
|
||
|
||
### Верификация баланса
|
||
|
||
Открытое арифметическое сравнение. Узел проверяет:
|
||
|
||
```
|
||
sender != receiver
|
||
amount > 0
|
||
sender.balance >= amount
|
||
```
|
||
|
||
`sender != receiver` запрещает self-transfer — иначе атакующий мог бы наращивать account_chain_length каждое окно через no-op переводы себе.
|
||
|
||
При settle (apply at window close):
|
||
|
||
```
|
||
sender.balance -= amount
|
||
receiver.balance += amount
|
||
```
|
||
|
||
Баланс обновляется не при cement (~0.3 сек), а в конце окна при батчевом apply. Между cement и settle операция необратима но баланс ещё не изменён. Никаких proofs, никакой криптографии помимо подписи и хэша.
|
||
|
||
### Anti-inflation
|
||
|
||
Чеканка из воздуха невозможна через локальный инвариант на каждом state transition.
|
||
|
||
**Per-user-operation invariant.** Каждое применение пользовательской операции обязано удовлетворять `Σ delta_balance == 0`:
|
||
|
||
```
|
||
Transfer: sender.balance -= amount, receiver.balance += amount → Σ = 0
|
||
OpenAccount: новый аккаунт с balance = 0 → Σ = 0
|
||
ChangeKey: только обновление current_pubkey → Σ = 0
|
||
Anchor: только запись data_hash → Σ = 0
|
||
```
|
||
|
||
**Per-proposal invariant.** Каждый финализированный proposal окна τ₁ обязан удовлетворять `delta_supply == +60 Ɉ`:
|
||
|
||
```
|
||
apply_proposal step 2 (TimeCoin emission):
|
||
если winner_class = Node: operator_account.balance += 60_000_000_000 nɈ
|
||
если winner_class = Account: winner_account.balance += 60_000_000_000 nɈ
|
||
|
||
delta_supply за proposal = +60_000_000_000 nɈ ровно один раз
|
||
```
|
||
|
||
O(1) проверка на каждое state transition. Глобальный инвариант `Σ balance == 60 Ɉ × (window_index + 1)` истинен по индукции от genesis при условии что каждый переход поддерживает per-operation invariant.
|
||
|
||
```
|
||
genesis state (аксиома): window_index не определён, supply = 0, Σ balance = 0
|
||
первое окно: window_index = 0, supply = 60 Ɉ, Σ balance = 60 Ɉ
|
||
окно k: window_index = k, supply = 60 × (k+1) Ɉ, Σ balance = 60 × (k+1) Ɉ
|
||
```
|
||
|
||
Никаких откатов cemented операций не требуется — каждое cemented локально валидно по конструкции.
|
||
|
||
**τ₂ sanity check.** Дополнительная проверка раз в τ₂: пересчёт `Σ balance` по всей Account Table и сравнение с `60 Ɉ × (window_index + 1)`. Не load-bearing для финализации — служит для обнаружения багов реализации. Расхождение = немедленная остановка узла, дамп state для расследования.
|
||
|
||
### Перевод
|
||
|
||
Перевод на несуществующий account_id — отклоняется. Получатель обязан существовать в Account Table до получения перевода.
|
||
|
||
### TimeCoin
|
||
|
||
Победитель τ₁ записывает прошедшее время: 60 Ɉ (60 зарегистрированных секунд). При финализации proposal окна:
|
||
|
||
```
|
||
если winner_class = Node: operator_account.balance += 60_000_000_000 nɈ
|
||
если winner_class = Account: winner_account.balance += 60_000_000_000 nɈ
|
||
```
|
||
|
||
Атомарное обновление баланса. Узел получает награду через привязанный operator_account (зафиксирован при NodeRegistration). Никаких отдельных coinbase-структур, никаких отдельных таблиц эмиссии. Зачисление есть состояние Account Table.
|
||
|
||
```
|
||
Публичное (верифицируемо всеми):
|
||
TimeCoin: 60 Ɉ за окно (константа)
|
||
Supply audit: supply(window_index) = 60_000_000_000 × (window_index + 1) nɈ
|
||
Winner: winner_id в proposal header
|
||
Все балансы: Account Table
|
||
Все переводы: цепочки операций аккаунтов
|
||
VDF: TimeChain values, NodeChain endpoints, подписи
|
||
```
|
||
|
||
Псевдонимность на уровне account_id (как Bitcoin). Финансовая приватность — задача приложений: микшеры, payment channels, off-chain settlements. Не задача протокола.
|
||
|
||
### Двойная трата
|
||
|
||
Каждый аккаунт имеет одну цепочку. Две операции с одним prev_hash = equivocation.
|
||
|
||
**Без конфликта:** операция → узлы валидируют → публикуют confirmation → quorum → cemented (необратимо, ~0.3 сек). Баланс обновляется при settle (apply at window close).
|
||
|
||
**При конфликте (equivocation):**
|
||
|
||
1. Узел получает операцию X с prev_hash = H. Узел уже видел операцию Y с prev_hash = H, Y ≠ X. Форк обнаружен. Обе операции помечаются как equivocated.
|
||
2. Если одна операция уже cemented (quorum до обнаружения конфликта) — cemented необратимо. Вторая отклоняется.
|
||
3. Если ни одна не cemented — узлы продолжают собирать confirmations для обеих. Если одна набирает quorum → cemented, вторая отклоняется.
|
||
4. Если через 10 окон ни одна не набрала quorum → обе отклоняются окончательно. Аккаунт продолжает с последней cemented операции. Владелец отправляет новую операцию.
|
||
|
||
Equivocation создаётся только владельцем аккаунта (требуется подпись). Третья сторона не может создать equivocation для чужого аккаунта. Стимул: двойная трата = потеря обеих операций.
|
||
|
||
### Антиспам
|
||
|
||
Ноль комиссий — антиспам через время. Право на операцию = доказанное время существования аккаунта.
|
||
|
||
#### Приоритет операции
|
||
|
||
```
|
||
account_age = current_window - creation_window
|
||
priority(op) = account_age × windows_since_last_op
|
||
```
|
||
|
||
`account_age` — возраст аккаунта в окнах. Растёт линейно. Некупуемый. `windows_since_last_op` — окна с последней операции аккаунта. Сбрасывается при каждой операции. Спамер обнуляет приоритет с каждой операцией — самонаказание.
|
||
|
||
При переполнении ёмкости сети — операции с наименьшим приоритетом ожидают следующего окна.
|
||
|
||
#### Бакеты по account_age
|
||
|
||
Изоляция спама. Каждый аккаунт может опубликовать максимум одну операцию за окно τ₁ (dependency rule). При переполнении сети (больше операций в мемпуле чем пропускная способность окна) — бакеты определяют **приоритет включения**. Round-robin по бакетам: одна операция из бакета 0, одна из бакета 1, ..., по кругу. Спам в бакете 0 не вытесняет операции из бакетов 1-3.
|
||
|
||
```
|
||
Бакет 0: account_age < 4τ₂
|
||
Бакет 1: account_age 4τ₂ — 16τ₂
|
||
Бакет 2: account_age 16τ₂ — 64τ₂
|
||
Бакет 3: account_age 64τ₂+
|
||
```
|
||
|
||
Границы бакетов = 4^N × τ₂. Все аккаунты: максимум 1 операция за τ₁. Бакет определяет приоритет при переполнении, не потолок TPS.
|
||
|
||
Новый аккаунт — бакет 0 с момента создания. 1 операция в минуту. Вход без ожидания: получил перевод → сразу можешь отправить.
|
||
|
||
#### Throughput на аккаунт
|
||
|
||
1 операция за τ₁ (60 секунд). Это консервативно: Bitcoin — 1 операция в 10 минут. Один Anchor содержит Merkle root от произвольного количества записей — throughput данных не ограничен. Для высокочастотных переводов — payment channels или application-level batching.
|
||
|
||
Спамер с 1000 новых аккаунтов: 1000 операций за τ₁ в бакете 0. Бакет 0 получает 1/4 от round-robin. Изолирован. Аккаунты в бакетах 1-3 не замечают.
|
||
|
||
---
|
||
|
||
## Состояние сети
|
||
|
||
Глобальное состояние = Account Table + Node Table + Invitation Table.
|
||
|
||
```
|
||
Account Table (запись на аккаунт):
|
||
account_id 32B <- = SHA-256("mt-account" || suite_id || pubkey)
|
||
balance 16B <- u128 nɈ, открыт
|
||
suite_id 2B
|
||
is_node_operator 1B <- 1 если аккаунт привязан как operator узла; исключён из лотереи аккаунтов
|
||
frontier_hash 32B <- хэш последней операции в цепочке
|
||
op_height 4B <- количество операций в цепочке
|
||
account_chain_length 4B <- количество уникальных окон τ₁ с операцией (длина AccountChain), live
|
||
account_chain_length_snapshot 4B <- snapshot account_chain_length на последнюю τ₂ boundary, используется лотереей
|
||
current_pubkey 897B <- FN-DSA-512
|
||
creation_window 4B <- окно создания аккаунта (OpenAccount)
|
||
last_op_window 4B <- окно последней операции (для приоритета)
|
||
|
||
Node Table (запись на узел):
|
||
node_id 32B <- SHA-256("mt-node" || node_pubkey), верифицируемо
|
||
node_pubkey 897B
|
||
suite_id 2B
|
||
operator_account_id 32B <- account_id куда зачисляется TimeCoin при победе узла; неизменен после регистрации
|
||
start_window 8B <- u64, окно регистрации (первое окно NodeChain)
|
||
chain_length 8B <- u64, число окон с cemented BundledConfirmation узла; инкрементируется в apply at window close
|
||
last_confirmation_window 8B <- u64, window_index последнего окна с cemented BundledConfirmation
|
||
|
||
Invitation Table (запись на приглашение):
|
||
invitation_id 32B <- SHA-256("mt-invitation" || inviter_node_id || invited_pubkey || invite_window)
|
||
inviter_node_id 32B <- node_id пригласившего узла
|
||
invited_pubkey 897B <- FN-DSA-512 публичный ключ приглашённого
|
||
invited_node_id 32B <- = SHA-256("mt-node" || invited_pubkey), derived
|
||
invite_window 8B <- u64, окно apply NodeInvitation
|
||
invite_expires 8B <- u64, invite_window + 21 160 (1 000 окон запас сверх 14 дней VDF)
|
||
|
||
```
|
||
|
||
**Active node predicate (derived).** Узел считается активным если опубликовал cemented BundledConfirmation за последние 2τ₂:
|
||
|
||
```
|
||
active(node, W) = (W - node.last_confirmation_window) <= 2 × τ₂_windows
|
||
```
|
||
|
||
Predicate не хранится в state — вычисляется из `last_confirmation_window` и текущего `window_index`. Применяется в quorum, confirmation_threshold, лотерее, валидации NodeRegistration.
|
||
|
||
**Quota predicate (derived).** Количество одновременно активных приглашений узла:
|
||
|
||
```
|
||
invites_active(N) = |{ inv ∈ Invitation Table : inv.inviter_node_id == N }|
|
||
```
|
||
|
||
Не хранится в state — вычисляется сканированием Invitation Table (≤ 10³ записей при росте сети, миллисекунды). Используется при валидации NodeInvitation: пригласитель допускается если `invites_active(N) < quota(bucket(N.chain_length))`.
|
||
|
||
Семантика «одновременно активных» закрывает атаку на τ₂ boundary: записи expired/consumed удаляются из таблицы, slot освобождается, новое приглашение создаётся. Узел не может удвоить квоту через границу epoch. Пропускная способность узла-инвайтера определяется частотой completion циклов (≈14 дней на одно VDF), не календарным окном τ₂.
|
||
|
||
Invitation как объект первого класса. Каждое приглашение — независимая запись с собственным lifecycle (created → expired или created → consumed by NodeRegistration). Узел-инвайтер может держать N параллельных приглашений ограниченных только квотой бакета. Single-slot конфликтов нет конструкцией.
|
||
|
||
### State Root
|
||
|
||
Merkle-дерево глобального состояния. Три подкорня обновляются при применении операций (apply_proposal и apply at window close):
|
||
|
||
```
|
||
state_root = SHA-256("mt-state-root" || node_root || invitation_root || account_root)
|
||
|
||
node_root: Merkle root Node Table, обновляется при apply NodeRegistration,
|
||
chain_length increment (apply step 3.5), pruning узлов на τ₂.
|
||
invitation_root: Merkle root Invitation Table, обновляется при apply NodeInvitation
|
||
(создание), apply NodeRegistration (удаление), apply step 3 (expiry),
|
||
cascade при pruning узла-инвайтера.
|
||
account_root: Merkle root Account Table, обновляется батчем при apply at window
|
||
close (все cemented операции окна применяются к state, затем
|
||
account_root пересчитывается).
|
||
|
||
Все три root соответствуют settled state (после apply at window close). Они не обновляются на каждую индивидуальную cemented операцию (нет "live root"), а применяются батчами, обеспечивая единый и верифицируемый state_root.
|
||
Порядок node_root → invitation_root → account_root отражает направление
|
||
зависимостей: узлы существуют первичны, приглашения связывают существующих
|
||
с будущими узлами, аккаунты — финансовый слой над всем.
|
||
Domain separator `mt-state-root` отличён от `mt-merkle-node`
|
||
(используемого для внутренних узлов Merkle tree) — hash spaces не пересекаются.
|
||
```
|
||
|
||
**Структура Account Table Root:**
|
||
|
||
Sparse Merkle tree глубины 256, индексированный по `account_id`:
|
||
|
||
```
|
||
leaf_hash(account) = SHA-256("mt-merkle-leaf" || serialize(account_record))
|
||
internal(left, right) = SHA-256("mt-merkle-node" || left || right)
|
||
empty_leaf = 0x00 × 32
|
||
|
||
account_root = root of sparse Merkle tree over Account Table
|
||
```
|
||
|
||
Обновление одного аккаунта пересчитывает ровно `log₂(N)` хэшей пути от листа к корню — для N=10⁹ аккаунтов это 30 SHA-256 вычислений (~60 µs CPU).
|
||
|
||
**Структура Node Table Root:** аналогично, sparse Merkle tree по `node_id`. Размер сети ≤ 10⁵ узлов → пути ~17 хэшей.
|
||
|
||
**Структура Invitation Table Root:** sparse Merkle tree глубины 256, индексированный по `invitation_id`. Размер ≤ 10³ записей при росте сети → пути ~10 хэшей. Empty root = `0x00 × 32`.
|
||
|
||
Каждый узел в Node Table — участник сети. Узел существует в таблице = участвует.
|
||
|
||
Все sort keys фиксированной длины. Побайтовое лексикографическое сравнение. Две реализации с одинаковыми данными строят одинаковое дерево и получают одинаковый State Root.
|
||
|
||
State Root коммитится в заголовке каждого proposal τ₁. `account_root`, `node_root` и `invitation_root` соответствуют settled state после apply at window close — все cemented операции окна W применены к таблицам перед сборкой proposal.
|
||
|
||
#### Inclusion proof
|
||
|
||
Любой cemented аккаунт может предоставить доказательство существования в state:
|
||
|
||
```
|
||
proof = Merkle path длиной log₂(N) (~30 хэшей для N=10⁹)
|
||
verify(proof, account_record, account_root):
|
||
reconstruct path bottom-up; compare с account_root
|
||
```
|
||
|
||
Доказательство верифицируется против `account_root` любого финализированного proposal начиная с окна когда состояние было обновлено. Не нужны архивы операций — текущее состояние самодостаточно.
|
||
|
||
#### Pruning
|
||
|
||
На τ₂ boundary применяется pruning неактивных аккаунтов:
|
||
|
||
```
|
||
Удалить все записи Account Table где:
|
||
balance == 0 <- нулевой баланс
|
||
AND last_op_window + 4τ₂ <= current_window <- нет активности 4τ₂ (56 дней)
|
||
AND is_node_operator == 0 <- не привязан как operator узла
|
||
AND нет cemented NodeRegistration в control_set <- нет pending привязки
|
||
ожидающего apply, ссылающегося на этот account_id
|
||
```
|
||
|
||
Пустой аккаунт без активности 56 дней — удаляется, кроме:
|
||
- Operator-аккаунтов уже зарегистрированных узлов (`is_node_operator == 1`)
|
||
- Аккаунтов на которые ссылается cemented NodeRegistration ожидающий apply
|
||
|
||
Без второго исключения возможна race: NodeRegistration cemented (operator валиден), pruning применился до apply этого NodeRegistration → аккаунт удалён → apply отклонён. Защита: pruning не трогает аккаунты, на которые есть cemented pending registration.
|
||
|
||
Каждое удаление пересчитывает соответствующий путь в Merkle tree (logarithmic). Pruning детерминирован, автоматичен, каноничен.
|
||
|
||
**Recovery semantics.** Воссоздание pruned аккаунта через новый OpenAccount с тем же ключом создаёт **новую цепочку**: frontier_hash начинается заново, op_height сбрасывается в 1, account_chain_length = 0. Старые prev_hash references на цепочку до pruning отклоняются — цепочка удалена из текущего state. История переводов до pruning не восстанавливается из текущего Account Table, но навсегда сохранена в proposals. Восстановление истории возможно через scan архива proposals.
|
||
|
||
---
|
||
|
||
## Двигатели
|
||
|
||
Четыре цепочки с односторонним потоком зависимостей: TimeChain → NodeChain → AccountChain → AccountTable.
|
||
|
||
TimeChain — глобальные часы (ход времени). NodeChain — машинное присутствие узла (непрерывное VDF). AccountChain — человеческое присутствие аккаунта (дискретные операции). AccountTable — состояние счёта.
|
||
|
||
### TimeChain VDF — осциллятор
|
||
|
||
Первичный продукт протокола. Непрерывная последовательная SHA-256 цепочка — цифровой осциллятор Montana Time:
|
||
|
||
```
|
||
T_r = SHA-256^D(T_{r-1})
|
||
```
|
||
|
||
D — количество последовательных хэшей за одно окно τ₁. Каждый хэш — один тик осциллятора. D хэшей — одно колебание. TimeChain продвигается по расписанию окон. Для фиксированного индекса r значение T_r совпадает у всех честных узлов. Каждый узел вычисляет TimeChain независимо — результат детерминирован.
|
||
|
||
TimeChain не зависит от состояния, транзакций и поведения отдельных узлов. Даже при отказе всего Account слоя часы продолжают тикать.
|
||
|
||
### NodeChain — персональная цепочка узла
|
||
|
||
Криптографическое доказательство присутствия конкретного node_id при каждом тике часов. Якорится в TimeChain каждое окно:
|
||
|
||
```
|
||
S_{i,s,0} = SHA-256(S_{i,s-1,m} || T_s || node_id_i)
|
||
S_{i,s,j+1} = SHA-256(S_{i,s,j}) для j = 0..m-1
|
||
```
|
||
|
||
Три компонента seed: предыдущий endpoint (непрерывность цепочки), значение TimeChain (протокольное время), node_id (идентичность). m последовательных хэшей за окно — одно звено NodeChain.
|
||
|
||
Инициализация: для первого окна нового узла предыдущий endpoint отсутствует. NodeChain init привязан к каноническим данным proposal в котором NodeInvitation финализирован:
|
||
|
||
```
|
||
S_{i,0,0} = SHA-256("mt-nodechain-init" || control_root || timechain_value || node_id_i)
|
||
```
|
||
|
||
control_root и timechain_value из proposal header окна финализации Invitation. Оба канонические (не зависят от субъективного user_set). Предвычисление VDF невозможно — timechain_value неизвестен до закрытия окна. Grinding surface = ноль. Верифицируем любым узлом.
|
||
|
||
NodeChain зависит от TimeChain. TimeChain не зависит от NodeChain.
|
||
|
||
### AccountChain — персональная цепочка аккаунта
|
||
|
||
Криптографическое доказательство присутствия конкретного account_id в дискретных моментах. Каждое звено — финализированная операция аккаунта (Transfer, OpenAccount, ChangeKey, Anchor). Linking через `prev_hash` (хэш предыдущей операции в цепочке аккаунта). Якорится в TimeChain через timechain_value момента финализации каждой операции.
|
||
|
||
Длина AccountChain — количество окон τ₁ в которых аккаунт имел cemented операцию:
|
||
|
||
```
|
||
account_chain_length(account, W) = | { w : w <= W, аккаунт имел cemented операцию в окне w } |
|
||
```
|
||
|
||
Dependency rule ограничивает аккаунт одной операцией за окно τ₁ — поэтому длина AccountChain совпадает с числом окон активности. Поле `account_chain_length` хранится в Account Table, обновляется при apply операции:
|
||
|
||
```
|
||
on_operation_applied(operation, window W):
|
||
account = operation.account_id
|
||
account.account_chain_length += 1
|
||
account.last_op_window = W
|
||
account.op_height += 1
|
||
```
|
||
|
||
**Параллелизм с NodeChain:**
|
||
|
||
| Свойство | NodeChain | AccountChain |
|
||
|----------|-----------|--------------|
|
||
| Источник | node_pubkey | account_pubkey |
|
||
| Идентификатор | node_id | account_id |
|
||
| Тип присутствия | машинное | человеческое |
|
||
| Ритм | непрерывный (каждое окно VDF) | дискретный (окно с операцией) |
|
||
| Длина | chain_length (окна) | account_chain_length (окна) |
|
||
| Единица длины | окно τ₁ | окно τ₁ |
|
||
| Накопление | автоматически с каждым окном | через активность пользователя |
|
||
| Якорь во времени | timechain_value каждое окно | timechain_value окна с операцией |
|
||
| Защита от подделки | VDF необратим | подпись FN-DSA-512 |
|
||
| Linking | endpoint предыдущего звена | prev_hash предыдущей операции |
|
||
| Защита от Sybil | 14 дней VDF + invite slot | накопление окон требует реального времени |
|
||
|
||
Узел доказывает присутствие непрерывной работой машины в каждом окне. Аккаунт доказывает присутствие активным использованием сети — каждая операция фиксирует одно окно человеческого бытия на временной шкале Montana. Оба механизма математически верифицируемы, оба производят запись на одной шкале времени.
|
||
|
||
AccountChain зависит от TimeChain напрямую — каждая операция привязана к timechain_value момента финализации. AccountChain не зависит от NodeChain по построению — цепочка аккаунта существует независимо от того какой узел победил в окне финализации.
|
||
|
||
### VDF Reveal и лотерея
|
||
|
||
В лотерее участвуют два класса субъектов: **узлы** (через NodeChain) и **аккаунты** (через AccountChain). Каждый класс производит ticket взвешенный по длине своей цепочки. Lowest weighted_ticket из объединённого множества кандидатов выигрывает 60 Ɉ.
|
||
|
||
#### Класс 1: узлы
|
||
|
||
После закрытия окна τ₁ каждый узел вычисляет свой ticket:
|
||
|
||
```
|
||
ticket_node = -ln(endpoint_node / 2^256)
|
||
weighted_ticket_node = ticket_node / chain_length
|
||
```
|
||
|
||
Если weighted_ticket_node < target — узел кандидат и публикует VDF_Reveal:
|
||
|
||
```
|
||
VDF_Reveal:
|
||
node_id 32B
|
||
window_index 4B <- индекс τ₁
|
||
endpoint 32B <- S_{i,s,m}
|
||
start_window 4B <- окно начала NodeChain (для верификации)
|
||
signature 666B <- FN-DSA-512, подписано node_pubkey
|
||
Итого: ~738B
|
||
```
|
||
|
||
#### Класс 2: аккаунты
|
||
|
||
Аккаунт автоматически становится кандидатом если у него есть финализированная операция в окне W. Никакой отдельный reveal не публикуется — операция уже cemented в сети, endpoint вычисляется детерминированно любым узлом.
|
||
|
||
```
|
||
operation_for_lottery(account, W) = единственная cemented операция аккаунта в окне W
|
||
(dependency rule: максимум одна)
|
||
|
||
endpoint_account(W) = SHA-256(
|
||
"mt-account-lottery" ||
|
||
account_id ||
|
||
hash(operation_for_lottery) ||
|
||
timechain_value(W)
|
||
)
|
||
|
||
account_length_at_lottery = account.account_chain_length_snapshot
|
||
|
||
ticket_account = -ln(endpoint_account / 2^256)
|
||
weighted_ticket_account = ticket_account / account_length_at_lottery
|
||
```
|
||
|
||
`account_chain_length_snapshot` обновляется на каждой τ₂ boundary копией текущего `account_chain_length`. Между τ₂ boundaries snapshot frozen — все узлы используют одно значение, лотерея детерминирована. Live `account_chain_length` продолжает расти от cemented операций, но не используется лотереей до следующего τ₂.
|
||
|
||
Если weighted_ticket_account < target — аккаунт кандидат. Аккаунт без операции в окне W не участвует в лотерее этого окна.
|
||
|
||
**Исключение operator-аккаунтов.** Аккаунт с `is_node_operator = 1` исключён из лотереи аккаунтов даже если у него есть операция в окне. Узел получает вес через NodeChain (через свой node_id); operator_account только хранит TimeCoin. Двойной счёт исключён конструкцией. Оператор узла, желающий участвовать в лотерее аккаунтов, использует отдельный персональный аккаунт без NodeRegistration привязки.
|
||
|
||
**Защита от grinding:** dependency rule ограничивает аккаунт одной операцией за окно — один лотерейный билет, нет выбора «лучшей» операции. timechain_value(W) известен только после закрытия окна — endpoint не предсказуем заранее.
|
||
|
||
#### Победитель окна
|
||
|
||
```
|
||
candidates = node_candidates ∪ account_candidates
|
||
winner = argmin(weighted_ticket(c) for c in candidates)
|
||
winner получает TIME_RECORD = 60 Ɉ
|
||
```
|
||
|
||
**Формирование Proposal (Proposer Logic):**
|
||
Роли winner (получатель 60 Ɉ) и proposer (узел, собирающий и подписывающий proposal) строго разделены:
|
||
- `winner_id` определяется абсолютным минимумом среди всех weighted_tickets (и узлов, и аккаунтов). Он забирает награду.
|
||
- `proposer_node_id` всегда назначается узлу-кандидату с минимальным weighted_ticket в этом окне (возможно совпадает с победителем, если победил узел).
|
||
|
||
Узел-proposer собирает proposal без дополнительной награды (это обязанность валидатора). Proposal содержит `winner_id` победившего аккаунта (или узла).
|
||
|
||
**Если в окне нет узлов-кандидатов и есть аккаунты-кандидаты:** победитель выбирается среди аккаунтов. Proposal формирует ближайший активный узел (fallback к узлу с lowest ticket, даже если он не успел с VDF), без дополнительной награды.
|
||
|
||
#### Калибровка target
|
||
|
||
Target калиброван на ~12 кандидатов за окно (включая обоих классов). Калибровка на τ₂:
|
||
|
||
```
|
||
target_new = target_old × (12 / actual_candidates_per_window)
|
||
actual_candidates_per_window = total_candidates_за_τ₂ / 20 160
|
||
```
|
||
|
||
Трафик reveal за окно: ~12 узловых reveals × 738B ≈ 8.9 KB. Аккаунты не публикуют отдельные reveals — их операции уже в gossip.
|
||
|
||
#### Валидация reveal узла
|
||
|
||
1. Подпись FN-DSA-512 соответствует node_pubkey из Node Table
|
||
2. window_index = только что закрытый τ₁
|
||
3. node_id существует в Node Table
|
||
4. weighted_ticket < target
|
||
5. endpoint верифицируем: пересчёт NodeChain VDF от предыдущего endpoint
|
||
|
||
#### Валидация участия аккаунта
|
||
|
||
1. account_id существует в Account Table
|
||
2. account_chain_length_snapshot > 0
|
||
3. У аккаунта есть хотя бы одна cemented операция в окне W
|
||
4. operation_for_lottery определена детерминированно
|
||
5. weighted_ticket_account < target
|
||
|
||
### Account — содержимое блока
|
||
|
||
Приём, верификация объектов и формирование набора. Два класса объектов:
|
||
|
||
**UserObjects** — пользовательские операции:
|
||
|
||
| Тип | Описание | Валидация |
|
||
|-----|----------|-----------|
|
||
| Transfer | Публичный перевод | FN-DSA-512 подпись, prev_hash, sender != receiver, amount > 0, sender.balance >= amount, получатель существует |
|
||
| OpenAccount | Создание аккаунта | FN-DSA-512 подпись, prev_hash = 0, account_id = SHA-256("mt-account" || pubkey) не существует в Account Table |
|
||
| ChangeKey | Смена ключа | FN-DSA-512 подпись старым ключом, new_pubkey |
|
||
| Anchor | Якорь данных ко времени | FN-DSA-512 подпись, prev_hash, app_id = 32B, data_hash = 32B |
|
||
|
||
**ControlObjects** — объекты управляющие составом сети:
|
||
|
||
| Тип | Описание | Валидация |
|
||
|-----|----------|-----------|
|
||
| NodeInvitation | Приглашение нового узла | FN-DSA-512 подпись пригласившего, активный inviter, invites_active < квота бакета, invited_pubkey не зарегистрирован |
|
||
| NodeRegistration | Регистрация узла | FN-DSA-512 подпись, node_id уникален, proof_endpoint верифицируем через VDF, приглашение существует |
|
||
|
||
Каждый узел валидирует объекты обоих классов локально при получении. Валидные объекты ретранслируются по P2P.
|
||
|
||
Все объекты — UserObjects и ControlObjects — финализируются (cemented) одинаково: через 67% active_chain_length подтверждения в BundledConfirmation. Cemented status объективен и одинаков для всех узлов. Дискреция победителя над включением ControlObjects = ноль.
|
||
|
||
#### Proposal
|
||
|
||
Proposal содержит **control_set** и метаданные окна. UserObjects применяются к Account Table батчем при settle (apply at window close); в proposal они не повторяются. ControlObjects применяются к Node Table в apply_proposal step 1 в детерминированном порядке.
|
||
|
||
**control_set(proposal окна W)** определён формулой:
|
||
|
||
```
|
||
control_set = {
|
||
ControlObject c :
|
||
c.cemented_window > previous_proposal.window
|
||
AND c.cemented_window <= W
|
||
}
|
||
|
||
сортировка: (cemented_window asc, op_hash lex asc)
|
||
```
|
||
|
||
Где `previous_proposal.window` — окно предыдущего финализированного proposal в цепочке. Множество детерминировано: cemented_window — каноническое поле объекта (известно всем узлам через BundledConfirmation), op_hash — детерминирован.
|
||
|
||
Победитель **обязан** включить весь control_set целиком. Пропуск или добавление лишнего ControlObject = невалидный proposal = fallback. Каждый узел независимо вычисляет ожидаемый control_set по той же формуле и сравнивает с proposer's set.
|
||
|
||
Форки аккаунтов (две операции с одним prev_hash) разрешаются голосованием узлов весом chain_length. 67% active_chain_length за одну операцию → побеждает (см. раздел «Двойная трата»).
|
||
|
||
#### Дедлайн в окне
|
||
|
||
```
|
||
|-------- τ₁ (60 сек) --------|------- R (12 сек) -------|
|
||
^ ^ ^
|
||
T_close confirmation reveal_cutoff
|
||
cutoff (T+R/2) + apply trigger
|
||
+ proposal collect
|
||
```
|
||
|
||
- **T_close** — момент закрытия окна (детерминирован TimeChain advance к T_{W+1}).
|
||
- **confirmation_cutoff** = T_close + R/2. BundledConfirmation окна W, опубликованные позже, игнорируются. Cemented set окна W становится детерминированным.
|
||
- **reveal_cutoff** = T_close + R. VDF_Reveal принимается до этого момента. После reveal_cutoff: батч apply всех cemented операций окна W, обновление Account Table и Node Table, сборка proposal с актуальными account_root и node_root.
|
||
- ControlObjects не имеют отдельного cutoff — они попадают в control_set следующего proposal по моменту cement.
|
||
|
||
R, F — калибруются в τ₂ (см. раздел «Калибровка R, F»). Генезис: R₀ = 12s, F₀ = 12s.
|
||
|
||
После reveal_cutoff: определяется `winner_id` лотереи (получатель 60 Ɉ) и `proposer_node_id` (узел-кандидат с минимальным weighted_ticket). Исключительно этот узел-proposer собирает и подписывает proposal от имени всей сети.
|
||
|
||
#### Proposer
|
||
|
||
Proposer (proposer_node_id) собирает proposal:
|
||
- **control_set**: все cemented ControlObjects в окнах (previous_proposal.window, W] (формула выше). Свобода = ноль.
|
||
- **State Root snapshot**: account_root, node_root и invitation_root после apply at window close (все cemented операции и control objects окна W применены батчем)
|
||
|
||
Свобода proposer: ноль. control_set детерминирован формулой. State root вычисляется после батчевого apply — каждый узел независимо применяет один и тот же cemented set и получает один и тот же результат.
|
||
|
||
Proposal с пропущенным cemented ControlObject, добавленным non-cemented ControlObject, неверным порядком или неверным state_root отклоняется, переход ко второму месту.
|
||
|
||
#### Финальность proposal
|
||
|
||
Финальность proposal = подпись proposer_node_id на proposal header (верифицируемая против Node Table[proposer_node_id].node_pubkey) + независимая верифицируемость состояния.
|
||
|
||
1. Proposer (proposer_node_id) публикует подписанный proposal header + control_set
|
||
2. Каждый узел проверяет `window_index == prev_proposal.window_index + 1`, `protocol_version >= prev_proposal.protocol_version` и `protocol_version <= local_max_supported_version`
|
||
3. Каждый узел проверяет wall_clock в bounds [expected_window_time(window_index) - 12, expected_window_time(window_index) + 12]
|
||
4. Каждый узел независимо вычисляет ожидаемый control_set по формуле и сравнивает с proposer's
|
||
5. Каждый узел применяет control_set + TimeCoin детерминированно в порядке (cemented_window asc, op_hash lex asc)
|
||
6. Каждый узел сравнивает вычисленный state_root с заявленным в proposal
|
||
7. Совпадает — proposal принят
|
||
8. Не совпадает — proposal отклонён, fallback на второе место
|
||
|
||
Финальность операций аккаунтов — отдельный процесс через подтверждения (67% active_chain_length), не через proposal.
|
||
|
||
Proposal header:
|
||
|
||
```
|
||
Proposal header:
|
||
prev_proposal_hash 32B
|
||
window_index 8B <- u64, индекс окна τ₁ с genesis; == prev_proposal.window_index + 1
|
||
protocol_version 4B <- u32, активная версия протокола на момент window_index
|
||
control_root 32B <- Merkle root control_set (каноничен)
|
||
node_root 32B <- Merkle root Node Table (обновляется каждое окно)
|
||
invitation_root 32B <- Merkle root Invitation Table
|
||
account_root 32B <- Merkle root Account Table после apply at window close
|
||
state_root 32B <- SHA-256("mt-state-root" || node_root || invitation_root || account_root)
|
||
timechain_value 32B
|
||
winner_class 1B <- 1=Node, 2=Account
|
||
winner_endpoint 32B <- NodeChain endpoint winner-а (если winner_class=1)
|
||
иначе endpoint_account вычисляемый
|
||
winner_id 32B <- получатель TimeCoin: node_id (winner_class=1)
|
||
или account_id (winner_class=2)
|
||
proposer_node_id 32B <- узел собравший и подписавший proposal;
|
||
если winner_class=1, proposer_node_id == winner_id;
|
||
если winner_class=2, proposer_node_id = node-кандидат
|
||
с минимальным weighted_ticket (или fallback)
|
||
target 8B <- текущий target лотереи
|
||
wall_clock 8B <- секунды с генезиса (локальное измерение proposer),
|
||
валиден в [expected_window_time(window_index) - 12,
|
||
expected_window_time(window_index) + 12]
|
||
fallback_depth 1B <- 1 = первое место, 2+ = fallback
|
||
signature 666B <- FN-DSA-512, подпись header Node Table[proposer_node_id].node_pubkey
|
||
```
|
||
|
||
**Разделение ролей winner_id и proposer_node_id.** Это два независимых поля с разными назначениями:
|
||
|
||
- `winner_id` — получатель TimeCoin. Аккаунт или узел, выигравший лотерею окна. Используется только в apply_proposal step 2 для зачисления 60 Ɉ.
|
||
- `proposer_node_id` — узел ответственный за сборку и публикацию proposal. Подписывает header своим node_pubkey. Верификация подписи proposal — против `Node Table[proposer_node_id].node_pubkey`, всегда.
|
||
|
||
Когда `winner_class = Account`, winner — это аккаунт без node_pubkey, физически не способный подписать proposal. Подписывает всегда узел-proposer (ближайший по weighted_ticket). TimeCoin при этом получает winner (аккаунт), proposer не получает дополнительной награды.
|
||
|
||
**Инварианты Proposal header:**
|
||
|
||
- `window_index == prev_proposal.window_index + 1` (монотонность, шаг 1)
|
||
- `protocol_version >= prev_proposal.protocol_version` (не убывает; изменяется только через software upgrade узла, см. раздел «Эволюция протокола»)
|
||
- `protocol_version <= local_max_supported_version` (узел **обязан отклонить** proposal с protocol_version которую его реализация не поддерживает; принятие неизвестной версии = принятие непроверяемых правил = нарушение безопасности)
|
||
- `wall_clock` в bounds [expected_window_time(window_index) − 12, expected_window_time(window_index) + 12]
|
||
- `wall_clock > prev_proposal.wall_clock` (строгая монотонность)
|
||
|
||
**Cemented window** объекта — `window_index` proposal-а в котором BundledConfirmation с этим объектом достиг quorum. Определён детерминированно для каждого cemented объекта.
|
||
|
||
**Settled window** объекта — `window_index` proposal-а в котором объект был применён к state:
|
||
- Для UserObjects: `settled_window = cemented_window` (apply batch at window close того же окна). Следующая операция от того же sender возможна в окне `cemented_window + 1` (dependency rule)
|
||
- Для ControlObjects: `settled_window` = window_index первого proposal где объект попал в control_set (обычно `cemented_window + 1`)
|
||
|
||
Fallback: если proposal от назначенного proposer_node_id не получен в пределах timeout (F секунд после reveal_cutoff) или отклонён — proposal формирует следующий узел-кандидат по weighted_ticket. При fallback меняется только **proposer_node_id**; `winner_id` и распределение TimeCoin всегда сохраняются (60 Ɉ всё равно уходит изначальному победительному ticket-у). Новый proposer_node_id подписывает header своим node_pubkey, `fallback_depth` инкрементируется.
|
||
|
||
**Полная симметрия fallback:**
|
||
Молчание первого proposer никогда не лишает winner награды — оно только переводит обязанность сборки proposal к следующему узлу. Независимо от того, является ли `winner` узлом или аккаунтом, награда привязана к лотерейному билету и гарантирована, если хотя бы один узел в сети соберёт валидный proposal через механизм fallback. F калибруется в τ₂ (см. раздел «Калибровка R, F»).
|
||
|
||
#### Непрерывность VDF
|
||
|
||
VDF следующего окна вычисляется непрерывно, не ожидая завершения финализации предыдущего. TimeChain для окна N+1 детерминирован — каждый узел вычисляет его независимо. NodeChain для окна N+1 стартует сразу после закрытия окна N, используя собственный endpoint текущего окна и новое значение TimeChain. Reveal phase и финализация происходят параллельно с началом VDF следующего окна.
|
||
|
||
#### Confirmations (финализация операций и control objects)
|
||
|
||
Confirmers — узлы с chain_length >= confirmation_threshold. Подтверждают **все** валидные объекты окна (UserObjects + ControlObjects) от имени сети.
|
||
|
||
```
|
||
active_chain_length(W) = Σ node.chain_length
|
||
для node ∈ Node Table : active(node, W)
|
||
|
||
confirmation_threshold(W) = active_chain_length(W) / 100
|
||
~100 confirmers при любом размере сети.
|
||
```
|
||
|
||
Только активные узлы (cemented BundledConfirmation за последние 2τ₂) учитываются. Мёртвый вес исключён конструкцией. Сканирование Node Table для вычисления `active_chain_length` — O(|Node Table|) ≤ 10⁵ записей, миллисекунды.
|
||
|
||
Confirmer собирает все валидные объекты за окно (без разделения на классы) и публикует один BundledConfirmation:
|
||
|
||
```
|
||
BundledConfirmation:
|
||
node_id 32B
|
||
endpoint 32B <- текущий NodeChain endpoint (доказывает chain_length)
|
||
window_index 4B
|
||
op_count 2B
|
||
op_hashes[] op_count × 32B <- хэши UserObjects и ControlObjects вместе
|
||
signature 666B
|
||
```
|
||
|
||
Один BundledConfirmation per (node_id, window_index). Повторный отклоняется. Endpoint верифицируем: пересчёт m хэшей от предыдущего известного endpoint данного узла. `node.chain_length` хранится в Node Table и инкрементируется в `apply_proposal` шаг 3.5 для каждого узла с cemented BundledConfirmation в окне W. Endpoint BundledConfirmation верифицирует вычисление VDF за соответствующее окно.
|
||
|
||
Объект финализирован (cemented) когда подтверждения от confirmers с суммарным chain_length > quorum. Cemented — необратимо. Типичное время: ~0.3 секунды. Это правило применяется одинаково к UserObjects и ControlObjects: cemented status объективен и каноничен для всех узлов.
|
||
|
||
**Confirmation cutoff (детерминизм cemented set).** Confirmer обязан опубликовать BundledConfirmation окна W до момента `T_W_close + R/2` (половина reveal окна). BundledConfirmation окна W, полученные после этого момента, **игнорируются** при вычислении cemented set окна W. Cutoff делает множество cemented operations окна W объективным и одинаковым у всех узлов: любой узел собирает confirmations за окно W до T_W_close + R/2 → независимо вычисляет один и тот же cemented set.
|
||
|
||
**Dependency rule (детерминизм apply).** Одно правило: confirmer подтверждает операцию только если все её зависимости разрешены из settled state окна W-1.
|
||
|
||
```
|
||
Операция валидна для inclusion в BundledConfirmation окна W если:
|
||
1. prev_hash == Account Table[sender].frontier_hash
|
||
на момент settled state конца окна W-1
|
||
2. Для Transfer: receiver существует в Account Table
|
||
на момент settled state конца окна W-1
|
||
3. sender.balance >= amount (для Transfer)
|
||
на момент settled state конца окна W-1
|
||
```
|
||
|
||
Settled state конца окна W-1 — результат apply_proposal окна W-1 — одинаков у всех узлов (детерминированная функция от cemented set W-1 и предыдущего state). Confirmer проверяет каждую операцию против этого глобально единого состояния. Никаких bundle-local цепочек, никакого mempool order.
|
||
|
||
**Следствие: одна операция на аккаунт за окно τ₁.** Вторая операция от того же sender имеет prev_hash = H(первой операции), но первая ещё не settled (settled = конец текущего окна W). Confirmer отклоняет вторую. Она пройдёт в окне W+1 когда первая settled. Throughput на аккаунт: 1 операция в 60 секунд. Это достаточно для всех бытовых сценариев; для высокочастотных — batching через Anchor (один Anchor содержит Merkle root тысяч записей).
|
||
|
||
Cross-account зависимости сериализуются через окна — создание аккаунта OpenAccount в окне W, получение перевода в окне W+1.
|
||
|
||
```
|
||
quorum(W) = ⌈0.67 × active_chain_length(W)⌉
|
||
```
|
||
|
||
Объект cemented когда суммарный chain_length confirmers подтвердивших объект через BundledConfirmation окна W ≥ quorum(W). Активный набор детерминирован — все узлы вычисляют `active_chain_length(W)` независимо из state Node Table и получают одно и то же значение.
|
||
|
||
Если active_chain_length падает ниже минимума жизнеспособности (теоретически возможно при массовом offline) — финализация останавливается до восстановления активности. Halt by liveness, не by safety: вернувшиеся узлы возобновляют работу с последнего cemented state.
|
||
|
||
Трафик confirmations: ~100 bundles × ~4 KB ≈ 400 KB за окно. Стабильно при любом масштабе.
|
||
|
||
Узлы-наблюдатели (chain_length < threshold) получают bundles, верифицируют endpoint и подписи, подсчитывают quorum, применяют cemented операции. Не публикуют confirmations.
|
||
|
||
#### State transition
|
||
|
||
Два параллельных процесса обновления состояния:
|
||
|
||
**Применение операций по window close.** Cemented операции окна W буферизуются до confirmation cutoff (T_W_close + R/2). После cutoff множество cemented операций детерминировано. На момент T_W_close + R (момент сборки proposal) все cemented операции окна W применяются батчем в детерминированном порядке:
|
||
|
||
```
|
||
Порядок apply: по op_hash lex asc
|
||
```
|
||
|
||
Каждый аккаунт имеет максимум одну cemented операцию в окне W (dependency rule). Порядок между аккаунтами — лексикографически по op_hash. Детерминирован, вычислим независимо каждым узлом.
|
||
|
||
Apply каждой операции:
|
||
|
||
```
|
||
Transfer: sender.balance -= amount
|
||
receiver.balance += amount
|
||
sender.frontier_hash = H(operation)
|
||
update_merkle_path(sender)
|
||
update_merkle_path(receiver)
|
||
|
||
OpenAccount: создать запись в Account Table (balance = 0, pubkey, frontier_hash = H(op))
|
||
insert_merkle_leaf(new_account)
|
||
|
||
ChangeKey: account.current_pubkey = new_pubkey
|
||
account.suite_id = new_suite_id
|
||
account.frontier_hash = H(operation)
|
||
update_merkle_path(account)
|
||
|
||
Anchor: записать data_hash в цепочку аккаунта (frontier_hash обновлён)
|
||
update_merkle_path(account)
|
||
|
||
После каждой операции: account_root = current root.
|
||
```
|
||
|
||
**При apply каждой операции** обновляется AccountChain length signer-аккаунта (подписавшего операцию):
|
||
|
||
```
|
||
on_operation_applied(operation, window W):
|
||
signer = operation.sender # account_id из payload
|
||
signer.account_chain_length += 1
|
||
signer.last_op_window = W
|
||
signer.op_height += 1
|
||
# Получатель Transfer не получает обновления chain_length —
|
||
# пассивное получение не считается активностью.
|
||
```
|
||
|
||
Dependency rule: один аккаунт = одна операция за окно τ₁. Каждая cemented операция = +1 к account_chain_length = одно окно присутствия.
|
||
|
||
**State transition в proposal:** при settle (apply at window close) применяется атомарно:
|
||
|
||
```
|
||
apply_proposal(state, proposal) -> state':
|
||
|
||
Шаг 1: применить control_set в порядке (cemented_window asc, op_hash lex asc).
|
||
NodeInvitation: создать запись в Invitation Table:
|
||
invitation_id = SHA-256("mt-invitation" || inviter_node_id || invited_pubkey || W_p)
|
||
inviter_node_id = inviter_node_id
|
||
invited_pubkey = invited_pubkey
|
||
invited_node_id = SHA-256("mt-node" || invited_pubkey)
|
||
invite_window = W_p
|
||
invite_expires = W_p + 21 160
|
||
Node Table инвайтера не изменяется.
|
||
NodeRegistration: найти запись inv в Invitation Table по (inviter_node_id, invited_node_id == node_id),
|
||
проверить inv.invite_expires > W_p,
|
||
создать запись в Node Table (start_window = W_p, chain_length = 0,
|
||
last_confirmation_window = 0, operator_account_id зафиксирован),
|
||
установить is_node_operator = 1 у operator-аккаунта,
|
||
удалить запись inv из Invitation Table.
|
||
|
||
Шаг 2: применить TimeCoin победителя.
|
||
Если winner_class = 1 (Node): operator_account = Node Table[winner_id].operator_account_id
|
||
operator_account.balance += 60_000_000_000 nɈ
|
||
Если winner_class = 2 (Account): Account Table[winner_id].balance += 60_000_000_000 nɈ
|
||
Proposer (proposer_node_id) формирует proposal без награды.
|
||
|
||
Шаг 3: обработать expiry.
|
||
Все записи inv ∈ Invitation Table где inv.invite_expires <= current_window:
|
||
удалить inv из Invitation Table, обновить invitation_root.
|
||
|
||
Шаг 3.5: обновить chain_length активных узлов.
|
||
Для каждого узла N с cemented BundledConfirmation в окне W:
|
||
N.chain_length += 1
|
||
N.last_confirmation_window = W
|
||
update_merkle_path(N) в node_root
|
||
Множество узлов с cemented BundledConfirmation в окне W детерминировано
|
||
(cemented status объективен) — все узлы применяют один и тот же набор обновлений.
|
||
|
||
Шаг 4: node_root, invitation_root и account_root уже отражают все cemented изменения
|
||
(incremental Merkle update произошёл при каждом state transition).
|
||
state_root = SHA-256("mt-state-root" || node_root || invitation_root || account_root).
|
||
```
|
||
|
||
Порядок детерминирован. Каждый узел применяет одни и те же шаги и получает один и тот же state_root.
|
||
|
||
AccountTable зависит от TimeChain, NodeChain и AccountChain. Обратных зависимостей нет.
|
||
|
||
С ростом TPS сети дополнительные ядра подключаются для верификации операций. Минимум для валидатора: 3 логических ядра (TimeChain + NodeChain + Account). Один узел = 3 ядра. 50 ядер = 16 узлов. Верификация операций аккаунтов полностью параллелизуется — цепочки аккаунтов независимы.
|
||
|
||
### Приглашение и регистрация
|
||
|
||
Два уровня входа в сеть. Узлы участвуют в консенсусе — приглашение + 14 дней VDF. Аккаунты держат и переводят средства — создаются явно через OpenAccount, без приглашений.
|
||
|
||
Генезис: 12 узлов в разных локациях (hardcoded, аналог bootstrap nodes в Bitcoin).
|
||
|
||
**Genesis State — аксиома сети.** Не результат операций, не финализация. Начальное состояние, существующее до того как любая операция возможна:
|
||
|
||
```
|
||
Genesis State (до первого окна, supply = 0):
|
||
|
||
Account Table = 12 хардкодированных записей:
|
||
account_id = SHA-256("mt-account" || suite_id || pubkey_i)
|
||
balance = 0
|
||
suite_id = 0x0001 (FN-DSA-512)
|
||
is_node_operator = 1
|
||
current_pubkey = pubkey_i (founder i)
|
||
frontier_hash = SHA-256("mt-genesis" || account_id)
|
||
op_height = 0
|
||
account_chain_length = 0
|
||
account_chain_length_snapshot = 0
|
||
creation_window = 0
|
||
(остальные поля = 0)
|
||
|
||
Node Table = 12 хардкодированных записей:
|
||
node_id = SHA-256("mt-node" || node_pubkey_i)
|
||
node_pubkey = node_pubkey_i (founder i)
|
||
suite_id = 0x0001
|
||
operator_account_id = account_id_i (i-я запись Account Table)
|
||
start_window = 0
|
||
chain_length = 0
|
||
last_confirmation_window = 0
|
||
|
||
Invitation Table = ∅ (пустая на genesis)
|
||
|
||
Genesis NodeChain init для каждого genesis-узла:
|
||
nodechain_init_i = SHA-256("mt-nodechain-genesis" || node_id_i)
|
||
|
||
Первое звено NodeChain в окне 0: S_{i,0,0} = nodechain_init_i.
|
||
Дальнейшие звенья по обычной формуле S_{i,s+1,0} = SHA-256(S_{i,s,m} || T_{s+1} || node_id_i).
|
||
|
||
genesis_account_root = sparse Merkle root над 12 записями Account Table
|
||
genesis_node_root = sparse Merkle root над 12 записями Node Table
|
||
genesis_invitation_root = 0x00 × 32 (пустая sparse Merkle tree)
|
||
genesis_state_root = SHA-256("mt-state-root" || genesis_node_root || genesis_invitation_root || genesis_account_root)
|
||
|
||
protocol_params (каноническая сериализация, little-endian, фиксированная длина полей):
|
||
D₀ (8B) начальная сложность TimeChain VDF
|
||
m₀ (8B) начальное число хэшей NodeChain за окно
|
||
R₀ (8B) начальный reveal timeout, секунды
|
||
F₀ (8B) начальный fallback timeout, секунды
|
||
τ₁_seconds (8B) длительность окна (60)
|
||
τ₂_windows (8B) число окон в τ₂ (20 160)
|
||
wall_clock_tolerance (8B) допустимое отклонение wall_clock от expected (12)
|
||
genesis_time_unix (8B) 1 736 380 800 (09.01.2026 00:00:00 UTC)
|
||
timecoin_per_window (16B) 60_000_000_000 nɈ (u128)
|
||
target₀ (32B) начальный target лотереи
|
||
confirmation_quorum_num (1B) 67
|
||
confirmation_quorum_den (1B) 100
|
||
invite_expiry_windows (8B) 21 160
|
||
pruning_idle_windows (8B) 80 640 (4τ₂)
|
||
founders_account_pubkeys (12 × 897B = 10 764 B)
|
||
founders_node_pubkeys (12 × 897B = 10 764 B)
|
||
genesis_content_app_id (32B) = SHA-256("mt-app" || "montana")
|
||
genesis_content_data_hash (32B) хэш манифеста книги Montana v1.0 (хардкодировано)
|
||
|
||
Genesis State Hash = SHA-256(genesis_state_root || protocol_params)
|
||
```
|
||
|
||
12 пар (pubkey, node_pubkey) основателей публикуются в Genesis Decree вместе с протокольными параметрами и финальным Genesis State Hash. Genesis Decree immutable — закреплён в коде каждой реализации и не может быть изменён без согласованного software upgrade всех узлов. `genesis_content_data_hash` обновляется аналогично — через новую версию ПО, не через runtime механизм.
|
||
|
||
Первое окно τ₁ после генезиса — window_index = 0, protocol_version = 1. Один из 12 узлов выигрывает лотерею → его operator_account.balance += 60_000_000_000 nɈ → supply = 60 Ɉ. Per-operation invariant начинает действовать с этого момента.
|
||
|
||
**Mandatory content replication.** Каждый узел Montana обязан хранить текущую версию книги Montana как persistent blob по (genesis_content_app_id, genesis_content_data_hash). При Fast Sync новый узел загружает genesis content как часть обязательной начальной синхронизации (см. раздел Fast Sync).
|
||
|
||
#### Приглашение узла (NodeInvitation)
|
||
|
||
Вход узла в консенсус. Приглашение + 14 дней VDF + регистрация. Квота определяет максимум **одновременно активных** приглашений узла, по chain_length бакету:
|
||
|
||
```
|
||
Бакет 0: chain_length 1-4 τ₂ 1 одновременное приглашение
|
||
Бакет 1: chain_length 4-16 τ₂ 4 одновременных приглашения
|
||
Бакет 2: chain_length 16-64 τ₂ 16 одновременных приглашений
|
||
Бакет 3: chain_length 64+ τ₂ 64 одновременных приглашения
|
||
```
|
||
|
||
Границы бакетов = 4^N × τ₂. Квота = 4^N одновременно активных. Та же формула что и для антиспам аккаунтов. Slot освобождается при completion (NodeRegistration cemented) или expiry (21 160 окон) — `invites_active(N)` уменьшается, узел может создать новое приглашение.
|
||
|
||
```
|
||
NodeInvitation:
|
||
type 1B <- 0x10 NodeInvitation
|
||
inviter_node_id 32B
|
||
invited_pubkey 897B <- публичный ключ приглашённого узла
|
||
signature 666B <- подписано inviter node_pubkey
|
||
Итого: ~1 596B
|
||
```
|
||
|
||
NodeInvitation — ControlObject. Не содержит start_window — определяется при apply (окно proposal в который invitation включена в control_set).
|
||
|
||
Валидация:
|
||
|
||
1. Подпись валидна для inviter node_pubkey из Node Table
|
||
2. inviter существует в Node Table и `active(inviter, current_window)`
|
||
3. `invites_active(inviter) < quota(bucket(inviter.chain_length))`
|
||
4. invited node_id = SHA-256("mt-node" || invited_pubkey) не существует в Node Table
|
||
5. Не существует записи в Invitation Table с тем же `(inviter_node_id, invited_pubkey)` в текущей τ₂-эпохе (защита от повторного приглашения того же ключа)
|
||
|
||
**Жизненный цикл NodeInvitation:**
|
||
1. Опубликована в окне W₀
|
||
2. Cemented в окне W_c через 67% active_chain_length confirmations (~0.3 сек)
|
||
3. Включена в control_set proposal окна W_p ≥ W_c (первый proposal после cement)
|
||
4. Применена в apply_proposal step 1 окна W_p — создание новой записи в Invitation Table
|
||
|
||
При apply (proposal P окна W_p) создаётся запись Invitation Table:
|
||
|
||
```
|
||
inv.invitation_id = SHA-256("mt-invitation" || inviter_node_id || invited_pubkey || W_p)
|
||
inv.inviter_node_id = inviter_node_id
|
||
inv.invited_pubkey = invited_pubkey
|
||
inv.invited_node_id = SHA-256("mt-node" || invited_pubkey)
|
||
inv.invite_window = W_p
|
||
inv.invite_expires = W_p + 21 160
|
||
```
|
||
|
||
Node Table инвайтера не изменяется. Множественные параллельные приглашения от одного узла создают независимые записи Invitation Table — single-slot конфликта нет.
|
||
|
||
#### Привязка NodeChain к моменту приглашения
|
||
|
||
Первое звено NodeChain приглашённого узла привязано к каноническим полям proposal в котором NodeInvitation финализирован:
|
||
|
||
```
|
||
nodechain_init = SHA-256("mt-nodechain-init" || control_root || timechain_value || node_id)
|
||
```
|
||
|
||
control_root и timechain_value — канонические поля из proposal header окна финализации. Не зависят от субъективного user_set победителя. Предвычисление VDF невозможно: timechain_value неизвестен до закрытия окна.
|
||
|
||
Приглашённый узел узнаёт control_root и timechain_value только увидев финализированный proposal → вычисляет nodechain_init → начинает NodeChain с окна W+1.
|
||
|
||
#### Регистрация узла
|
||
|
||
Приглашённый узел после финализации NodeInvitation:
|
||
|
||
1. Наблюдает proposal с NodeInvitation → получает control_root и timechain_value
|
||
2. Вычисляет nodechain_init = SHA-256("mt-nodechain-init" || control_root || timechain_value || node_id)
|
||
3. Непрерывно строит NodeChain: 20 160 окон подряд (от W+1 до W+20 160), каждое звено якорится в соответствующий TimeChain
|
||
4. Через ~14 дней получает proof_endpoint = S_{i,20159,m}
|
||
5. Публикует NodeRegistration
|
||
|
||
```
|
||
NodeRegistration:
|
||
type 1B <- 0x11 NodeRegistration
|
||
suite_id 2B
|
||
node_pubkey 897B <- FN-DSA-512 ключ узла
|
||
inviter_node_id 32B <- кто пригласил
|
||
operator_account_id 32B <- account_id оператора, должен существовать в Account Table
|
||
proof_endpoint 32B <- S_{i,20159,m} (endpoint после 20 160 окон VDF)
|
||
signature 666B <- подписано node_pubkey
|
||
Итого: ~1 662 B
|
||
```
|
||
|
||
NodeRegistration — ControlObject.
|
||
|
||
Валидация NodeRegistration:
|
||
|
||
1. Подпись FN-DSA-512 валидна для node_pubkey
|
||
2. node_id = SHA-256("mt-node" || node_pubkey) уникален (не существует в Node Table)
|
||
3. Существует запись `inv ∈ Invitation Table` где `inv.inviter_node_id == inviter_node_id` AND `inv.invited_node_id == node_id` AND `inv.invite_expires > current_window`
|
||
4. `inv.invite_window + 20 160 < current_window` (VDF завершён)
|
||
5. operator_account_id существует в Account Table и `is_node_operator == 0`
|
||
6. Восстановить control_root и timechain_value из proposal окна `inv.invite_window`
|
||
7. Вычислить `nodechain_init = SHA-256("mt-nodechain-init" || control_root || timechain_value || node_id)` из proposal окна `inv.invite_window`
|
||
8. proof_endpoint верифицируем: пересчёт VDF от nodechain_init через 20 160 окон с якорением в TimeChain значения от `inv.invite_window + 1`
|
||
|
||
Верификация: 20 160 сегментов VDF проверяются параллельно. На C ядрах: ~(20 160/C) × t_segment.
|
||
|
||
**Жизненный цикл NodeRegistration:**
|
||
1. Опубликована в окне W₀ (после 20 160 окон VDF от приглашения)
|
||
2. Cemented в окне W_c через 67% active_chain_length confirmations
|
||
3. Включена в control_set proposal окна W_p ≥ W_c
|
||
4. Применена в apply_proposal step 1 окна W_p
|
||
|
||
При apply:
|
||
- Проверить `Account Table[operator_account_id].is_node_operator == 0` — если 1, отклонить (другая NodeRegistration с тем же operator уже была применена раньше в порядке (cemented_window, op_hash))
|
||
- Создать запись в Node Table: `start_window = W_p`, `chain_length = 0`, `last_confirmation_window = 0`, operator_account_id зафиксирован
|
||
- Установить `is_node_operator = 1` у operator-аккаунта
|
||
- **Удалить запись `inv` из Invitation Table** (приглашение consumed)
|
||
|
||
#### Истечение приглашения узла
|
||
|
||
Если NodeRegistration не финализирован до `inv.invite_expires` (= `invite_window + 21 160`) — приглашённый не завершил VDF. В `apply_proposal` шаг 3 запись `inv` удаляется из Invitation Table автоматически. Slot инвайтера освобождается (`invites_active(N)` уменьшается на 1), узел может приглашать снова.
|
||
|
||
#### Создание аккаунта
|
||
|
||
Аккаунт не требует приглашений. Пользователь генерирует FN-DSA-512 keypair → вычисляет account_id = SHA-256("mt-account" || suite_id || pubkey) → публикует OpenAccount → операция cemented (~0.3 сек) → запись появляется в Account Table при settle (apply at window close). Адрес существует математически до публикации, но операции к нему отклоняются до settle OpenAccount.
|
||
|
||
Sybil-барьер для аккаунтов: account_age (возраст аккаунта) определяет квоту операций. Новый аккаунт — бакет 0, максимум 1 операция за τ₁. Рост квоты = время. Пустые аккаунты бесполезны — без баланса ничего не делают.
|
||
|
||
#### Скорость роста сети
|
||
|
||
Узлы: квота приглашений определяется chain_length бакетом (4^N за τ₂). Рост ограничен зрелостью сети:
|
||
|
||
```
|
||
Генезис (12 узлов, бакет 0): 12 × 1 = 12 приглашений за τ₂
|
||
После 4τ₂ (бакет 1): 12 × 4 = 48 приглашений за τ₂
|
||
После 16τ₂ (бакет 2): 12 × 16 = 192 приглашения за τ₂
|
||
После 64τ₂ (бакет 3): 12 × 64 = 768 приглашений за τ₂
|
||
```
|
||
|
||
Со временем барьер приглашений размывается: старые узлы приглашают больше, сеть растёт быстрее. Каждый приглашённый узел проходит 14 дней VDF независимо от квоты пригласившего.
|
||
|
||
Аккаунты: без ограничений. Любой владелец TimeCoin может создать аккаунт любому, переведя средства на новый адрес. Рост пользовательской базы не ограничен протоколом.
|
||
|
||
---
|
||
|
||
## Потоковая модель
|
||
|
||
Операции аккаунтов текут непрерывно. Узел получает операцию → проверяет подпись FN-DSA-512 и баланс (против settled state W-1) → передаёт в P2P gossip. Confirmers (~100 узлов с наибольшим chain_length) собирают операции за окно и публикуют BundledConfirmation.
|
||
|
||
Операция проходит два состояния:
|
||
- **Cemented** (~0.3 сек): 67% active_chain_length подтвердили. Операция необратима. Баланс ещё не обновлён.
|
||
- **Settled** (конец окна, ≤ 60 сек): все cemented операции окна применены к Account Table батчем. Баланс обновлён. state_root зафиксирован в proposal.
|
||
|
||
Два параллельных процесса:
|
||
- **Операции** подтверждаются непрерывно через confirmations (cement), применяются батчем в конце окна (settle)
|
||
- **Часы** тикают по расписанию окон τ₁ (TimeChain, NodeChain, лотерея, TimeCoin)
|
||
|
||
Кошелёк получателя отображает входящий перевод в два этапа: «confirmed» после cement (~0.3 сек), «settled» после apply at window close (≤ 60 сек). Между cement и settle операция уже необратима — различие только для UX индикации.
|
||
|
||
Цепочки аккаунтов полностью независимы. Операции разных аккаунтов обрабатываются параллельно без конфликтов.
|
||
|
||
---
|
||
|
||
## Временные слои (τ)
|
||
|
||
```
|
||
τ₁ (60с) → τ₂ (20 160 × τ₁ ≈ 14 дней)
|
||
```
|
||
|
||
Одно окно — τ₁. Всё остальное — производные.
|
||
|
||
### τ₁ — Окно (60 секунд)
|
||
|
||
Единственная единица протокольного времени. Регистрация времени и эмиссия.
|
||
|
||
- TimeChain продвигается на D хэшей
|
||
- NodeChain продвигается на m хэшей с якорем в текущем T_s
|
||
- Операции аккаунтов подтверждаются непрерывно через confirmations (cement), применяются батчем в конце окна (settle)
|
||
- control_set: все cemented ControlObjects из окон (previous_proposal.window, current_window] (каноничен)
|
||
- Кандидаты (~12) раскрывают NodeChain endpoint (reveal phase, R = 12 секунд)
|
||
- Лотерея: `ticket_i = -ln(endpoint_i / 2^256)`, победитель = lowest ticket среди кандидатов
|
||
- Proposer (proposer_node_id) публикует подписанный proposal
|
||
|
||
- Финальность proposal: подпись proposer_node_id на proposal header. Каждый валидатор применяет control_set + TimeCoin детерминированно и проверяет state_root
|
||
- TimeCoin: запись прошедшего времени (60 Ɉ = 60 секунд) → победителю
|
||
- Supply audit: суммарная эмиссия TimeCoin от генезиса сверяется с supply(window_index) из issuance schedule
|
||
- Разрешение форков: приоритет ветки с наибольшим суммарным TimeChain-доказательством
|
||
|
||
TimeChain safety: компрометация значения TimeChain требует нарушения свойства последовательности SHA-256 VDF.
|
||
|
||
TimeChain liveness: задержка продвижения TimeChain невозможна — TimeChain вычисляется каждым узлом независимо.
|
||
|
||
### τ₂ — Адаптация (20 160 × τ₁ ≈ 14 дней)
|
||
|
||
- Калибровка D и m (см. ниже)
|
||
- Калибровка R, F (см. ниже)
|
||
- Snapshot account_chain_length: для каждого аккаунта `account_chain_length_snapshot = account_chain_length`. Snapshot используется лотереей аккаунтов в течение следующего τ₂. Детерминированно для всех узлов
|
||
- Pruning Account Table: удаление пустых аккаунтов без активности 4τ₂ (56 дней) с обновлением Merkle путей
|
||
- Pruning Node Table: для каждого узла N где `(current_window - N.last_confirmation_window) > 8 × τ₂_windows`:
|
||
1. Если `N.operator_account_id` существует в Account Table — установить `Account Table[N.operator_account_id].is_node_operator = 0` (operator-аккаунт освобождается, может участвовать в лотерее аккаунтов)
|
||
2. **Cascade удаление invitations:** удалить все записи `inv ∈ Invitation Table` где `inv.inviter_node_id == N.node_id`. Приглашённые этими invitations теряют возможность зарегистрироваться (NodeRegistration не пройдёт валидацию — invitation запись отсутствует)
|
||
3. Удалить запись N из Node Table
|
||
4. Пересчитать node_root и invitation_root
|
||
- Supply audit (sanity check): Σ balance(account) для всех аккаунтов = 60_000_000_000 × (window_index + 1) nɈ
|
||
- Криптографическая амнезия: подписанные proposals сохраняются навсегда — верифицируемая цепочка state commitments. Proposals доказывают что конкретное состояние было закоммичено proposer-узлом; восстановление содержимого состояния требует snapshot или архива
|
||
- Пересчёт параметров размера окна τ₁
|
||
|
||
#### Калибровка D и m
|
||
|
||
Каждый proposal содержит `wall_clock` — секунды с генезиса по локальным часам proposer_node_id. Поле зажато детерминированными bounds:
|
||
|
||
```
|
||
expected_window_time(window_index) = genesis_time_unix + (window_index + 1) × τ₁_seconds
|
||
= 1 736 380 800 + (window_index + 1) × 60
|
||
(genesis 09.01.2026 00:00:00 UTC)
|
||
|
||
wall_clock_tolerance = 12 секунд (фиксировано в Genesis Decree)
|
||
|
||
Валидация wall_clock при получении proposal:
|
||
expected = expected_window_time(proposal.window_index)
|
||
expected - 12 <= wall_clock <= expected + 12 (зажат в ±12 сек от ожидаемого)
|
||
wall_clock > prev_proposal.wall_clock (монотонность)
|
||
```
|
||
|
||
Любой proposal с wall_clock вне bounds — отклоняется. Каждый узел независимо вычисляет expected_window_time из канонической формулы (window_index известен из proposal header) → объективная проверка без mempool/network состояния. Proposer имеет ~24 секунды свободы — недостаточно чтобы сдвинуть медиану 20 160 значений за τ₂ значимо.
|
||
|
||
Медиана 20 160 wall_clocks за τ₂ — распределённый эталон скорости сети. Атака на медиану ограничена: при доле побед p максимальный сдвиг ~p × 12 сек, что меньше нормальной hardware drift volatility.
|
||
|
||
Формула пересчёта D на границе τ₂:
|
||
|
||
```
|
||
intervals[i] = proposal[i].wall_clock - proposal[i-1].wall_clock
|
||
для i = 1..20 159
|
||
|
||
actual_interval = median(intervals)
|
||
target_interval = 60
|
||
|
||
D_new = D_old × target_interval / actual_interval
|
||
D_new = clamp(D_new, D_old × 0.5, D_old × 1.5)
|
||
```
|
||
|
||
Формула точная — D корректируется ровно пропорционально отклонению. Страховочный clamp ±50% защищает от чёрного лебедя (массовый выход узлов, аппаратная революция). При нормальной работе отклонение медианы от 60 секунд — единицы секунд, коррекция D — единицы процентов.
|
||
|
||
Медиана > 60 → окна медленнее цели → D слишком велик → уменьшить. Медиана < 60 → окна быстрее → D увеличить.
|
||
|
||
m калибруется пропорционально: `m_new = m_old × (D_new / D_old)`.
|
||
|
||
Генезис: D₀ и m₀ калибруются при запуске для целевых 60 секунд. Абсолютный якорь: 09.01.2026 00:00:00 UTC. Медиана 20 159 интервалов — для сдвига необходим контроль >50% proposals (>50% веса сети).
|
||
|
||
#### Калибровка R, F
|
||
|
||
Входные данные — из proposals за τ₂ (канонические, детерминированно вычисляются всеми узлами):
|
||
|
||
```
|
||
fallback_ratio = count(fallback_depth > 1) / 20160
|
||
```
|
||
|
||
Формула пересчёта:
|
||
|
||
```
|
||
R_new = clamp(R_old × fallback_ratio / fallback_target, R_old × 0.8, R_old × 1.2)
|
||
R_new = clamp(R_new, R_min, R_max)
|
||
|
||
F_new = clamp(F_old × fallback_ratio / fallback_target, F_old × 0.8, F_old × 1.2)
|
||
F_new = clamp(F_new, F_min, F_max)
|
||
```
|
||
|
||
Протокольные константы:
|
||
|
||
```
|
||
fallback_target = 5%
|
||
R_min = 4s, R_max = 30s
|
||
F_min = 4s, F_max = 30s
|
||
```
|
||
|
||
Генезис: R₀ = 12s, F₀ = 12s.
|
||
|
||
---
|
||
|
||
## Консенсус — Proof of Time (PoT)
|
||
|
||
### Четыре цепочки
|
||
|
||
**TimeChain** — глобальные часы. Чистая VDF-цепочка `T_r = SHA-256^D(T_{r-1})`. Первичный продукт протокола. Источник времени и случайности. Продвигается по расписанию окон.
|
||
|
||
**NodeChain** — персональная цепочка узла. VDF-цепочка конкретного node_id, якорится в TimeChain каждое окно. Доказывает непрерывную работу узла.
|
||
|
||
**Account** — состояние счёта. Операции финализируются непрерывно через подтверждения (67% active_chain_length). ControlObjects включаются в proposal (каноничен).
|
||
|
||
Зависимости односторонние: TimeChain → NodeChain → AccountChain → AccountTable. Отказ в AccountTable не останавливает часы. Отказ конкретного узла в NodeChain не заражает общий ритм.
|
||
|
||
### Лотерея
|
||
|
||
Лотерея объединяет два класса участников: узлы (через NodeChain) и аккаунты (через AccountChain). Каждый класс производит weighted ticket по длине своей цепочки. Lowest weighted_ticket из объединённого множества побеждает.
|
||
|
||
**Узлы** автоматически участвуют в каждом окне:
|
||
```
|
||
ticket_node = -ln(endpoint_node / 2^256)
|
||
weighted_ticket_node = ticket_node / chain_length
|
||
```
|
||
|
||
**Аккаунты** участвуют в окне с финализированной операцией:
|
||
```
|
||
ticket_account = -ln(endpoint_account / 2^256)
|
||
weighted_ticket_account = ticket_account / account_chain_length
|
||
```
|
||
|
||
`account_chain_length_snapshot` обновляется на τ₂ boundary, frozen до следующей τ₂ boundary. Лотерея использует snapshot — детерминированно для всех узлов.
|
||
|
||
Если weighted_ticket < target — субъект кандидат. Target калиброван на ~12 кандидатов за окно (включая оба класса). Из кандидатов побеждает lowest weighted_ticket.
|
||
|
||
**Стимул узла:** каждое окно с опубликованным BundledConfirmation увеличивает chain_length → увеличивает шанс победы. Пропущенное окно — это окно не входит в chain_length. Узел остаётся в Node Table и продолжает участвовать.
|
||
|
||
**Стимул аккаунта:** каждое окно с операцией увеличивает account_chain_length → реальный (хоть и редкий) шанс выиграть 60 Ɉ за активность в Montana.
|
||
|
||
### Победитель τ₁
|
||
|
||
Победитель определяется после закрытия окна τ₁. Lowest weighted_ticket из всех кандидатов (узлов и аккаунтов) = победитель.
|
||
|
||
**Если победил узел:**
|
||
- Записывает TimeChain value
|
||
- Operator account узла получает 60 Ɉ TimeCoin
|
||
- Коммитит State Root
|
||
- Формирует proposal (control_set + State Root + TimeCoin), подписывает node_pubkey
|
||
|
||
**Если победил аккаунт:**
|
||
- Аккаунт получает 60 Ɉ TimeCoin (winner_account.balance += 60_000_000_000 nɈ)
|
||
- Proposal формирует **узел-кандидат с минимальным weighted_ticket в этом окне** (proposer_node)
|
||
- Если в окне нет узлов-кандидатов — proposer выбирается из всех узлов с lowest weighted_ticket (fallback)
|
||
- Proposer не получает дополнительной награды — это его обязанность как ближайшего узла
|
||
|
||
Финальность proposal — подпись proposer_node_id на proposal header. Верификация — независимый пересчёт state_root.
|
||
|
||
### Верификация
|
||
|
||
Proposer публикует: `{proposer_node_id, NodeChain endpoint, proposal}`.
|
||
|
||
Верификация NodeChain за одно окно: пересчёт m хэшей. Параллелизация по сегментам — время верификации обратно пропорционально числу ядер.
|
||
|
||
Верификация proposal: независимое применение control_set + TimeCoin и сравнение state_root.
|
||
|
||
### Устойчивость
|
||
|
||
- **Остановка часов** исключена: каждый узел тикает независимо
|
||
- **Искажение часов** исключено: VDF последователен, результат детерминирован
|
||
- **Proposer grinding** исключён: control_set каноничен, state transition детерминирован, операции финализируются независимо от победителя
|
||
- **Front-running** исключён: операции финализируются через подтверждения (~0.3s), не через proposal proposer-а
|
||
- **Предвычисление** исключено: seed содержит текущее значение TimeChain
|
||
- **Replay** исключён: TimeChain уникален для каждого τ₁
|
||
- **Аппаратное преимущество** ограничено: последовательное хэширование масштабируется тактовой частотой, не количеством ядер
|
||
- **Sybil-барьер**: приглашение (квота по chain_length бакету, 4^N за τ₂) + 14 дней VDF + 3 ядра на узел + weighted_ticket в лотерее
|
||
- **Цензура операций** исключена: операции финализируются через подтверждения узлов, не через победителя
|
||
- **Цензура ControlObjects** исключена: control_set каноничен, пропуск = fallback
|
||
- **Liveness halt операций** исключён: финализация через 67% active_chain_length, не зависит от победителя
|
||
- **Liveness halt proposals** исключён: fallback на следующего кандидата
|
||
- **Масштабирование**: трафик лотереи ~8.9 KB за окно при любом количестве узлов
|
||
|
||
### Разрешение конфликтов
|
||
|
||
**Двойная операция аккаунта** (две операции с одним prev_hash): equivocation. Cemented до обнаружения — необратимо, вторая отклоняется. Не cemented — ожидание quorum 10 окон, затем обе отклоняются. См. раздел «Двойная трата».
|
||
|
||
**Невалидный proposal**: валидаторы отклоняют, fallback на следующего кандидата. Победитель теряет TimeCoin за это окно.
|
||
|
||
**Два proposal от одного proposer_node_id в одном окне**: оба отклоняются (equivocation), fallback к следующему узлу-кандидату. Если этот узел был winner (winner_class=1), он теряет TimeCoin.
|
||
|
||
---
|
||
|
||
## Адреса и переводы
|
||
|
||
### Полный флоу перевода
|
||
|
||
```
|
||
1. Боб: OpenAccount → cemented (~0.3 сек) → settled (конец окна) →
|
||
account_id зарегистрирован в Account Table (balance = 0)
|
||
2. Боб → Алисе: "отправь на mt4ZGfe..." (account_id Боба)
|
||
3. Алиса формирует Transfer (в следующем окне после settle OpenAccount Боба):
|
||
type: 0x02
|
||
prev_hash: хэш её предыдущей settled операции (frontier_hash из settled state W-1)
|
||
payload: sender (account_id Алисы) || link (account_id Боба) || amount (50_000_000_000 nɈ)
|
||
4. Алиса подписывает FN-DSA-512
|
||
5. Алиса рассылает операцию узлам сети
|
||
6. Каждый узел проверяет (против settled state W-1):
|
||
FN-DSA-512 подпись валидна для current_pubkey Алисы
|
||
prev_hash совпадает с frontier_hash Алисы
|
||
amount > 0
|
||
alice.balance >= amount
|
||
получатель (Боб) существует в Account Table
|
||
7. Confirmers публикуют BundledConfirmation, операция распространяется через P2P gossip
|
||
8. Cement: 67% active_chain_length подтвердили → операция необратима (~0.3 сек)
|
||
Кошелёк Боба отображает «confirmed»
|
||
9. Settle (apply at window close):
|
||
alice.balance -= 50 Ɉ
|
||
bob.balance += 50 Ɉ
|
||
alice.frontier_hash = H(operation)
|
||
alice.op_height += 1
|
||
alice.account_chain_length += 1
|
||
Кошелёк Боба отображает «settled»
|
||
```
|
||
|
||
### Баланс
|
||
|
||
Баланс аккаунта — открытое число `u128 nɈ` в Account Table. Обновляется при settle (apply at window close): исходящий Transfer вычитает amount, входящий зачисляет. Видим всем узлам и через любого верификатора цепочки.
|
||
|
||
Бэкап = seed (для деривации приватного ключа FN-DSA-512). Восстановление кошелька: ключ выводится из seed, баланс читается из текущего Account Table — никакого локального состояния не требуется.
|
||
|
||
---
|
||
|
||
## Эмиссия
|
||
|
||
### Единица
|
||
|
||
Монета: **TimeCoin** (тикер: $TimeCoin, символ: Ɉ).
|
||
|
||
1 секунда = 1 TimeCoin = 1 Ɉ = 1 000 mɈ = 1 000 000 μɈ = 1 000 000 000 nɈ
|
||
60 секунд = 1 минута = 60 TimeCoin
|
||
3 600 секунд = 1 час = 3 600 TimeCoin
|
||
86 400 секунд = 1 день = 86 400 TimeCoin
|
||
|
||
Одно окно τ₁ регистрирует 60 прошедших секунд = 60 TimeCoin.
|
||
|
||
Точность: 9 знаков после запятой (наносекунда). Все расчёты эмиссии в nɈ (целочисленная арифметика, без плавающей точки).
|
||
|
||
### Issuance schedule
|
||
|
||
Одна секунда протокольного времени порождает одну монету. С первого блока и навсегда.
|
||
|
||
| Параметр | Значение |
|
||
|----------|----------|
|
||
| Генезис | 09.01.2026 00:00:00 UTC |
|
||
| TIME_RECORD | 60 000 000 000 nɈ (60 Ɉ) |
|
||
|
||
### Регистрация времени
|
||
|
||
```
|
||
time_record(window_index) = 60_000_000_000 nɈ
|
||
```
|
||
|
||
Каждое окно τ₁ регистрирует 60 прошедших секунд = 60 Ɉ. Без халвингов, без фаз, без исключений. Одна константа на весь горизонт существования протокола.
|
||
|
||
### Supply audit
|
||
|
||
```
|
||
supply(window_index) = 60_000_000_000 × (window_index + 1) nɈ
|
||
```
|
||
|
||
Одно умножение. Проверяемо каждым узлом в каждом τ₁. O(1).
|
||
|
||
### Инфляция
|
||
|
||
Supply растёт линейно. Инфляция снижается асимптотически к нулю — константная эмиссия делится на растущий supply:
|
||
|
||
```
|
||
Год 1: 100%
|
||
Год 2: 50%
|
||
Год 5: 20%
|
||
Год 10: 10%
|
||
Год 50: 2%
|
||
Год 100: 1%
|
||
Год 1000: 0.1%
|
||
```
|
||
|
||
### Раннее участие
|
||
|
||
Эмиссия постоянна: 60 TimeCoin за каждое окно, с первого блока и навсегда. Вероятность победы пропорциональна весу. Узел, работающий дольше, побеждает чаще. Два узла запустившиеся одновременно имеют равные шансы независимо от капитала. Узел запустившийся раньше имеет преимущество — он доказал больше времени.
|
||
|
||
Стимул для ранних участников встроен в арифметику: не бонусы, не множители — просто больший вес.
|
||
|
||
### Распределение
|
||
|
||
Победитель окна τ₁ — узел или аккаунт — записывает прошедшее время и получает 60 Ɉ TimeCoin в своей цепочке. Одно правило. Неизменно с генезиса.
|
||
|
||
Узлы и аккаунты конкурируют в единой лотерее. Узлы доминируют статистически из-за непрерывного присутствия — chain_length растёт каждое окно, weighted_ticket систематически ниже. Аккаунты получают долю эмиссии пропорционально своей активности — account_chain_length растёт с каждым окном с операцией. Время — единственный арбитр.
|
||
|
||
Базовый бюджет: 60 Ɉ/τ₁ (запись 60 секунд). Реальный бюджет безопасности в покупательной способности зависит от рынка.
|
||
|
||
1 TimeCoin = 1 секунда описывает скорость хода часов. Не ценовой peg, не гарантия покупательной способности.
|
||
|
||
#### Двигатель роста сети
|
||
|
||
Участие аккаунтов в лотерее создаёт flywheel роста сети:
|
||
|
||
```
|
||
Активные пользователи в приложениях → AccountChain растёт → шансы в лотерее
|
||
↓ ↓
|
||
Приложения привлекают пользователей Иногда выигрывают TimeCoin
|
||
↓ ↓
|
||
Разработчики хотят пользователей Дополнительная мотивация активности
|
||
↓ ↓
|
||
Разработчики запускают узлы Montana Больше операций в сети
|
||
↓ ↓
|
||
Узлы зарабатывают TimeCoin Сеть растёт и децентрализуется
|
||
↓ ↓
|
||
Финансирование развития инфраструктуры → больше пропускной способности → лучше для приложений
|
||
```
|
||
|
||
Эмиссия 60 Ɉ за окно одна и та же, но финансирует обе стороны одновременно: узлы (поддержание сети) и активные пользователи (использование сети). Они не конкурируют — они взаимно усиливают друг друга. Это циркулярная экономика которой нет в Bitcoin.
|
||
|
||
### Reference Time Ratio
|
||
|
||
Reference Time Ratio (RTR) — эталонный коэффициент клиентского слоя, выражающий один BTC в единицах времени Montana через отношение эмиссионных правил Bitcoin и Montana.
|
||
|
||
RTR — не рыночная цена, не обменный курс и не рекомендация для торговли. RTR измеряет геометрию эмиссии, а не спрос, ликвидность или полезность актива.
|
||
|
||
#### Область действия
|
||
|
||
RTR существует только на клиентском слое.
|
||
|
||
- Не входит в state machine
|
||
- Не записывается в proposal header
|
||
- Не используется в консенсусе
|
||
- Не требует oracle, биржи или внешнего API
|
||
|
||
Узлы Montana выполняют консенсус без обращения к RTR.
|
||
|
||
#### Формула
|
||
|
||
Пусть n — индекс halving-эпохи Bitcoin (n = 0 для периода 2009-2012).
|
||
|
||
```
|
||
rtr_btc(n) = 12 × 2^n [Ɉ / BTC]
|
||
```
|
||
|
||
Вывод:
|
||
|
||
```
|
||
block_interval_btc = 600 секунд
|
||
block_reward_btc(n) = 50 / 2^n BTC
|
||
|
||
rtr_btc(n) = block_interval_btc / block_reward_btc(n)
|
||
= 600 / (50 / 2^n)
|
||
= 12 × 2^n
|
||
```
|
||
|
||
Поскольку 1 Ɉ = 1 секунда протокольного времени Montana, коэффициент напрямую выражается в Montana-секундах на 1 BTC.
|
||
|
||
#### Интерпретация
|
||
|
||
RTR отвечает на вопрос: сколько единиц времени Montana соответствует одному BTC в текущей subsidy-эпохе Bitcoin.
|
||
|
||
Это не оценка рыночной стоимости BTC. Это протокольное отношение двух эмиссионных кривых. Bitcoin уменьшает выпуск геометрически через halving. Montana добавляет время линейно: 60 Ɉ за окно. Из-за этого rtr_btc(n) удваивается на каждом halving Bitcoin.
|
||
|
||
#### Halving-эпохи
|
||
|
||
| n | Период (ориентир) | Block reward | RTR (Ɉ/BTC) |
|
||
|---|-------------------|--------------|-------------|
|
||
| 0 | 2009 — 2012 | 50 BTC | 12 |
|
||
| 1 | 2012 — 2016 | 25 BTC | 24 |
|
||
| 2 | 2016 — 2020 | 12.5 BTC | 48 |
|
||
| 3 | 2020 — 2024 | 6.25 BTC | 96 |
|
||
| 4 | 2024 — 2028 | 3.125 BTC | 192 |
|
||
| 5 | 2028 — 2032 | 1.5625 BTC | 384 |
|
||
| 6 | 2032 — 2036 | 0.78125 BTC | 768 |
|
||
| 7 | 2036 — 2040 | 0.390625 BTC | 1 536 |
|
||
| 8 | 2040 — 2044 | 0.1953125 BTC | 3 072 |
|
||
|
||
Границы эпох определяются Bitcoin block height: каждые 210 000 блоков. Даты — ориентировочные.
|
||
|
||
#### Свойства
|
||
|
||
- **Детерминизм.** Любой клиент получает одно и то же значение из Bitcoin block height.
|
||
- **Независимость от рынка.** Биржи, order book и внешние цены не участвуют.
|
||
- **Независимость от политики.** Значение не меняется голосованием Montana.
|
||
- **Историческая верифицируемость.** RTR для любой эпохи Bitcoin вычислим ретроспективно.
|
||
- **Простота.** Одна формула, без oracle и без внешней инфраструктуры.
|
||
|
||
#### Ограничения
|
||
|
||
RTR не измеряет:
|
||
|
||
- рыночную цену BTC
|
||
- справедливую стоимость BTC
|
||
- ликвидность
|
||
- волатильность
|
||
- комиссионный рынок Bitcoin
|
||
- спрос на Montana или Bitcoin
|
||
|
||
RTR корректно интерпретировать как reference time ratio, а не как price.
|
||
|
||
#### Использование
|
||
|
||
RTR может использоваться кошельками и приложениями для:
|
||
|
||
- отображения BTC в шкале времени Montana
|
||
- исторического сравнения halving-эпох
|
||
- UI-индикатора эмиссионного отношения Bitcoin и Montana
|
||
- образовательного слоя, объясняющего различие двух эмиссионных кривых
|
||
|
||
---
|
||
|
||
## Пропускная способность
|
||
|
||
Размер Transfer: ~779 B (открытый перевод, FN-DSA-512 подпись).
|
||
|
||
| Канал узла | TPS |
|
||
|-----------|-----|
|
||
| 10 Mbps | ~1 600 |
|
||
| 100 Mbps | ~16 000 |
|
||
| 1 Gbps | ~160 000 |
|
||
|
||
---
|
||
|
||
## Хранение
|
||
|
||
### Состояния операции (UX)
|
||
|
||
Операция проходит два различимых состояния:
|
||
|
||
```
|
||
publish ──→ cement (~0.3 сек) ──→ settle (≤ 60 сек)
|
||
"confirmed" "settled"
|
||
```
|
||
|
||
- **Cemented (~0.3 сек):** 67% active_chain_length подтвердили операцию через BundledConfirmation. Операция необратима и гарантированно будет применена в конце окна. Wallet показывает «confirmed».
|
||
- **Settled (≤ 60 сек, в конце окна):** все cemented операции окна применены батчем к Account Table в детерминированном порядке. account_root зафиксирован в proposal. Wallet показывает «settled».
|
||
|
||
Между cement и settle операция уже необратима — настройка двух UI-состояний нужна только для индикации завершённости state transition. Зависимые операции (Transfer на только что созданный аккаунт) сериализуются по окнам через confirmer dependency rule, поэтому cemented операция гарантированно settle-ится.
|
||
|
||
### Модель: глобальное состояние + локальная история
|
||
|
||
Узлы хранят глобальное состояние (Account Table, Node Table, Invitation Table, proposals). Тела операций аккаунтов хранятся у владельцев. После settle (apply at window close) state transition применён — балансы в таблице обновлены, тело операции сети больше не нужно.
|
||
|
||
### Три уровня участников
|
||
|
||
**Узел (валидатор)** — десктоп или сервер, 24/7, минимум 3 ядра (1 узел = 3 ядра, 50 ядер = 16 узлов):
|
||
|
||
```
|
||
Хранит:
|
||
Account Table (account_id, balance, frontier_hash, pubkey)
|
||
+ persistent sparse Merkle tree (account_root обновляется при settle)
|
||
Node Table (node_id, pubkey, start_window, chain_length)
|
||
+ persistent sparse Merkle tree (node_root обновляется при settle)
|
||
Invitation Table (invitation_id, inviter, invited, window, expires)
|
||
+ persistent sparse Merkle tree (invitation_root обновляется при settle)
|
||
Proposals (навсегда)
|
||
Blob Buffer (ephemeral) (TTL = τ₂, для кратковременных сообщений)
|
||
Persistent Blob Storage (TTL = 0, контент app_id на которые узел подписан)
|
||
Genesis Content (книга Montana, mandatory replication)
|
||
Persistent Blob Index ((app_id, data_hash) → blob, с флагом is_manifest)
|
||
|
||
Делает:
|
||
TimeChain VDF (1 ядро, 24/7)
|
||
NodeChain VDF (1 ядро, 24/7)
|
||
Валидация операций (1+ ядро)
|
||
P2P gossip (операции, confirmations, reveals, proposals)
|
||
Почтовый ящик (хранит сообщения для своего владельца пока тот офлайн)
|
||
Content replication (DHT provide, gossip announce, serving ContentRequest/ChunkRequest)
|
||
Chunk verification (SHA-256 + Merkle reconstruction для полученных чанков)
|
||
```
|
||
|
||
**Кошелёк (клиент)** — телефон, онлайн когда используется:
|
||
|
||
```
|
||
Хранит:
|
||
Свои ключи (seed → keypairs, включая encryption key для application layer)
|
||
Свои контакты (адресная книга: имя → mt-адрес, с локальным override)
|
||
Локальная история (своя цепочка операций для UX)
|
||
Сообщения (локальная история переписки, messenger session states)
|
||
Timestamp proofs (Anchor + BundledConfirmations + proposal headers, локально)
|
||
Подписки (app_id каналов, книги, профилей на которые подписан)
|
||
Реплики контента (persistent blobs подписанных app_id по желанию)
|
||
|
||
Делает:
|
||
Отправка/получение переводов
|
||
Мессенджер (P2P напрямую через libp2p)
|
||
Discovery (через application layer)
|
||
Запрос pubkey и proposals у узлов сети
|
||
```
|
||
|
||
**Доверенный узел** — узел друга, семьи, сообщества:
|
||
|
||
```
|
||
Делает:
|
||
Всё что узел + хранит Blob Buffer для привязанных аккаунтов
|
||
Владелец аккаунта привязывает свой account_id к доверенному узлу
|
||
Узел хранит зашифрованные сообщения (содержимое скрыто)
|
||
Владелец забирает сообщения когда появляется онлайн
|
||
```
|
||
|
||
### Размеры
|
||
|
||
| Участник | Данные | Размер |
|
||
|----------|--------|--------|
|
||
| Узел (1M аккаунтов) | Account Table + Node Table + Invitation Table + Proposals | ~2 GB |
|
||
| Узел (10M аккаунтов) | Account Table + Node Table + Invitation Table + Proposals | ~11 GB |
|
||
| Узел (100M аккаунтов) | Account Table + Node Table + Invitation Table + Proposals | ~101 GB |
|
||
| Кошелёк (обычный) | 100 операций/год + контакты + сообщения | ~1 MB |
|
||
| Кошелёк (активный) | 10 000 операций/год | ~16 MB |
|
||
| Корпорация | 1M Anchor/год | ~0.8 GB |
|
||
|
||
### Потеря данных клиента
|
||
|
||
Потеря устройства: баланс в Account Table цел и публичен, seed восстанавливает ключи, доступ к аккаунту полностью восстанавливается. Локальная история переводов и сообщений утрачена — но баланс читается из Account Table напрямую. Если есть доверенный узел — зашифрованные сообщения можно восстановить.
|
||
|
||
### Fast Sync (новый узел)
|
||
|
||
1. Цепочка proposals от генезиса — проверка TimeChain-цепочки и подписей proposer-узлов (мегабайты)
|
||
2. Snapshot трёх таблиц (Account Table + Node Table + Invitation Table) от пиров на момент окна W (произвольное недавнее окно)
|
||
3. Reconstructed `account_root`, `node_root` и `invitation_root` сравниваются с соответствующими полями из proposal окна W. Все три совпадают → snapshot валиден. Проверка `state_root = SHA-256("mt-state-root" || node_root || invitation_root || account_root)` — дополнительный integrity check.
|
||
4. Catch-up после окна W до текущего:
|
||
- Запросить cemented UserObjects и применить их батчем к Account Table по алгоритму apply at window close (включая проверку prev_hash и баланса).
|
||
- Запросить cemented ControlObjects (NodeInvitation, NodeRegistration) и применить их к Node Table и Invitation Table в детерминированном порядке.
|
||
- Выполнить incremental update Merkle trees (account_root, node_root, invitation_root) для отражения changes.
|
||
- На каждом промежуточном proposal сверять локальный state_root с заявленным в proposal header
|
||
5. **Mandatory genesis content replication.** Загрузить книгу Montana через Content Layer:
|
||
- ContentRequest(genesis_content_app_id, genesis_content_data_hash) → manifest
|
||
- Для каждого чанка: ChunkRequest + верификация SHA-256
|
||
- Пересчёт Merkle root манифеста → сравнение с genesis_content_data_hash
|
||
- Без успешной загрузки genesis content Fast Sync считается неполным
|
||
6. Узел синхронизирован и готов к участию
|
||
|
||
Snapshot привязан к конкретному proposal (settled state после apply at window close). Catch-up дистанция определяется свежестью snapshot, обычно минуты.
|
||
|
||
---
|
||
|
||
## Application Layer
|
||
|
||
Montana — цифровой стандарт времени. Приложения управляют своим состоянием самостоятельно (серверы, базы данных, P2P). Montana хранит только криптографические отпечатки с привязкой ко времени — 32 байта на запись.
|
||
|
||
### Модель приложения на Montana
|
||
|
||
Приложение Montana — это набор узлов с интерфейсом. Создатель приложения запускает узлы Montana (обычные узлы, тикающие VDF, валидирующие операции, участвующие в консенсусе). Узлы зарабатывают TimeCoin за поддержание сети через лотерею.
|
||
|
||
**Для создателя приложения:**
|
||
|
||
- Не нужно строить отдельную инфраструктуру безопасности — приватность данных через Anchor (хэш в сети, контент у владельца зашифрованным), антицензура через Transport Obfuscation и Dandelion++, децентрализация через отсутствие центрального сервера получаются бесплатно из протокола
|
||
- Бизнес-модель: эмиссия Montana через узлы создателя. Не реклама, не подписка, не продажа данных
|
||
- Чем больше пользователей в приложении → тем больше операций в сети → тем больше нужно узлов для обслуживания (Blob Buffer, валидация, P2P gossip) → больше узлов = больше шансов в лотерее = больше TimeCoin
|
||
|
||
**Для пользователя:**
|
||
|
||
- Каждое действие в приложении создаёт операцию в его AccountChain
|
||
- account_chain_length растёт автоматически с каждым окном с операцией
|
||
- Пользователь автоматически участвует в лотерее в каждом окне с операцией — без заявок, без стейкинга, без понимания криптографии
|
||
- Шанс победы зависит от account_chain_length — длинная активная цепочка даёт реальные шансы выиграть 60 Ɉ
|
||
- Ничего не привязано к конкретному приложению — seed принадлежит пользователю, account_id переходит между приложениями без потери истории
|
||
|
||
**Нулевая стоимость переключения приложений.** AccountChain пользователя — его собственность. Если приложение закрылось или пользователь хочет уйти — account_id, баланс, история и накопленный account_chain_length остаются. Пользователь продолжает в другом приложении на том же протоколе. Приложения вынуждены конкурировать качеством, а не замком.
|
||
|
||
### Двигатель роста сети через AccountChain
|
||
|
||
Лотерея Montana объединяет два класса участников: узлы (NodeChain) и аккаунты (AccountChain). Узлы доминируют статистически из-за непрерывного присутствия. Аккаунты получают долю эмиссии через активность пользователей. Эта механика создаёт самоподдерживающийся цикл роста сети — см. раздел "Эмиссия → Двигатель роста сети".
|
||
|
||
|
||
### Anchor
|
||
|
||
Одна операция, данные навсегда привязаны к timechain_value конкретного окна.
|
||
|
||
```
|
||
Anchor:
|
||
prev_hash 32B
|
||
account_id 32B
|
||
app_id 32B <- SHA-256("mt-app" || app_name)
|
||
data_hash 32B <- Merkle root, H(document), произвольный хэш
|
||
signature 666B
|
||
Итого: ~796B
|
||
```
|
||
|
||
app_id — детерминированный идентификатор пространства имён. Вычисляется из имени приложения, регистрация не требуется. Позволяет фильтровать, индексировать, строить лёгкие клиенты для конкретного приложения.
|
||
|
||
### Timestamp Proof
|
||
|
||
Стандартный формат доказательства: документ D существовал не позже момента T.
|
||
|
||
В модели v20.2.0 операции аккаунтов финализируются через BundledConfirmations узлов-confirmers, не через включение в proposal. Доказательство существования Anchor — набор подписанных подтверждений с суммарным chain_length ≥ quorum.
|
||
|
||
Proof собирается владельцем Anchor в момент финализации и хранится локально вместе с документом. Сеть не обязана хранить BundledConfirmations долгосрочно — ответственность за сохранение proof лежит на стороне, которой нужно доказать timestamp.
|
||
|
||
```
|
||
Структура proof:
|
||
1. Документ D и H(D)
|
||
2. Anchor body (prev_hash, account_id, app_id, data_hash, signature)
|
||
3. Если data_hash = MerkleRoot batch'а: Merkle path от H(D) до data_hash
|
||
4. Набор BundledConfirmations за окно W cementing'а Anchor:
|
||
- каждая содержит H(Anchor) в op_hashes[]
|
||
- каждая подписана confirmer node_pubkey
|
||
- каждая содержит endpoint NodeChain confirmer на момент окна W
|
||
- суммарный chain_length confirmers ≥ 67% active_chain_length(W)
|
||
5. Proposal header окна W (содержит timechain_value = T)
|
||
6. Цепочка proposal headers от W до genesis (через prev_proposal_hash)
|
||
|
||
Верификация любым третьим лицом, без доверия Montana-узлу:
|
||
1. Если есть Merkle path: пересчитать H(D) → data_hash, сравнить с data_hash в Anchor
|
||
2. Проверить FN-DSA-512 подпись на Anchor
|
||
3. Для каждой BundledConfirmation: проверить FN-DSA-512 подпись confirmer
|
||
4. Для каждой confirmation: пересчитать NodeChain endpoint от start_window до окна W,
|
||
подтвердить заявленный chain_length
|
||
5. Суммировать chain_length подтверждающих, проверить ≥ 67% active_chain_length(W)
|
||
6. Из proposal header окна W взять timechain_value = T
|
||
7. Пересчитать TimeChain VDF от proposal окна W до genesis по prev_proposal_hash
|
||
```
|
||
|
||
Proposals хранятся навсегда — timechain_value(W) и цепочка к genesis всегда доступны. BundledConfirmations хранятся локально владельцем proof. Timestamp proof самодостаточен и верифицируем в любой момент в будущем.
|
||
|
||
### Примеры
|
||
|
||
**Мессенджер.** Каждое сообщение хэшируется, цепочка хэшей формирует Merkle root, Merkle root записывается в Anchor раз в минуту или час. Montana хранит 32 байта — доказательство что набор сообщений существовал в конкретный момент. Подделать историю переписки невозможно — хэш не совпадёт.
|
||
|
||
**Архив документов.** Компания ежедневно записывает Merkle root документов. Через 10 лет регулятор спрашивает «существовал ли документ X на дату Y». Компания предоставляет документ, Merkle proof и ссылку на proposal. Верификация математическая.
|
||
|
||
**Социальная сеть.** Каждый пост привязан к Montana Time через Anchor. Порядок публикаций доказуем. Редактирование не скрывает оригинал — хэш оригинала уже в цепочке.
|
||
|
||
### Экономика
|
||
|
||
Anchor бесплатен. Тысячи приложений записывающих якоря — утилитарное использование Montana Time. Спрос на токен привязан к утилитарной функции: перевод ценности и запись времени, не спекуляция.
|
||
|
||
Не нужны смарт-контракты. Не нужен Turing-complete язык. Не нужен газ. Не нужны комиссии.
|
||
|
||
### Phone Discovery и Messenger
|
||
|
||
Phone discovery и messenger — полностью на Application Layer, не в protocol core. Protocol не знает о телефонах, именах, сообщениях. Application Layer реализует эти функции через Content Layer (см. ниже) и Interop Standards.
|
||
|
||
Протокол предоставляет:
|
||
- **Identity:** account_id через OpenAccount
|
||
- **Timestamping:** Anchor с произвольным data_hash
|
||
- **Storage:** Blob Buffer для хранения произвольных байт (persistent и ephemeral режимы)
|
||
- **Transport:** libp2p gossip и Content Request Protocol
|
||
|
||
Всё остальное — phone discovery, encryption, messaging protocols, profiles — реализуется на уровне приложения. Стандарты совместимости фиксированы в разделе Application Layer Interop Standards.
|
||
|
||
### Content Layer
|
||
|
||
Content Layer предоставляет механизм хранения и репликации произвольных данных между узлами с привязкой к Anchor. Узлы подписанные на app_id хранят контент этого app_id. Новый узел или узел восстанавливающийся после offline скачивает недостающие блобы у пиров, верифицирует целостность через хэши из Anchor. Целевая задача — децентрализованное облако данных где каждый подписчик является хранителем, а факт существования контента зафиксирован навсегда через Anchor в proposal chain.
|
||
|
||
#### Persistent Blob
|
||
|
||
Blob Buffer получает второй режим хранения:
|
||
|
||
- **TTL = τ₂** (ephemeral) — кратковременные сообщения, удаляются через τ₂
|
||
- **TTL = 0** (persistent) — контент привязанный к Anchor, хранится бессрочно пока узел подписан на соответствующий app_id
|
||
|
||
Persistent blob индексируется парой `(app_id, data_hash) → blob_bytes`. Блоб может содержать manifest чанкованного контента (флаг `is_manifest = true`) или один чанк/целый файл. Размер одного blob ограничен chunk_size. Удаление persistent blob — решение оператора узла через явную отписку от app_id, не автоматически по таймеру.
|
||
|
||
#### Chunking Standard
|
||
|
||
Большие файлы разбиваются на чанки фиксированного размера:
|
||
|
||
```
|
||
chunk_size = 256 KB (фиксировано протоколом)
|
||
|
||
chunk formaт: chunk_index (4B, u32) || chunk_data (≤262 144 bytes)
|
||
chunk_hash = SHA-256("mt-content-chunk" || chunk_data)
|
||
```
|
||
|
||
Manifest содержит метаданные файла и упорядоченный список chunk_hashes:
|
||
|
||
```
|
||
Manifest {
|
||
version: u16 (currently 1)
|
||
file_name: string (UTF-8, length-prefixed, max 256 bytes)
|
||
file_size: u64
|
||
mime_type: string (UTF-8, length-prefixed, max 64 bytes)
|
||
chunk_count: u32
|
||
chunk_hashes: [32B × chunk_count]
|
||
}
|
||
```
|
||
|
||
Merkle tree строится поверх chunk_hashes. Корень дерева:
|
||
|
||
```
|
||
data_hash = SHA-256("mt-content-manifest" || canonical_serialization(Manifest))
|
||
```
|
||
|
||
Этот `data_hash` записывается в Anchor. Маленький файл (< chunk_size) — один чанк, manifest с `chunk_count = 1`.
|
||
|
||
Manifest сохраняется как первый persistent blob по `(app_id, data_hash)` с флагом `is_manifest = true`. Индекс узла хранит эту связь, позволяя быстро находить manifest для любого Anchor.
|
||
|
||
#### Content Request Protocol
|
||
|
||
P2P сообщения libp2p для обмена контентом между узлами:
|
||
|
||
```
|
||
ContentRequest:
|
||
app_id 32B
|
||
data_hash 32B (data_hash из Anchor — manifest root)
|
||
|
||
ContentResponse:
|
||
status 1B (0 = ok, 1 = not_found, 2 = error)
|
||
payload variable (serialized Manifest если status = 0)
|
||
|
||
ChunkRequest:
|
||
data_hash 32B (data_hash манифеста)
|
||
chunk_index 4B
|
||
|
||
ChunkResponse:
|
||
status 1B
|
||
chunk_data variable (до chunk_size байт)
|
||
```
|
||
|
||
**Процесс верификации при получении:**
|
||
|
||
1. Получив Manifest: десериализовать, проверить каноническая форма, пересчитать `data_hash = SHA-256("mt-content-manifest" || serialization)`, сравнить с запрошенным
|
||
2. Получив чанк: пересчитать `chunk_hash = SHA-256("mt-content-chunk" || chunk_data)`, сравнить с соответствующим элементом `chunk_hashes` в manifest
|
||
3. После сбора всех чанков: пересчитать Merkle tree из chunk_hashes, сравнить корень с data_hash из Anchor в proposal
|
||
4. Любое несовпадение — отклонить ответ пира, запросить у другого пира, пометить нечестного пира в local blacklist транспорта
|
||
|
||
#### Content Discovery
|
||
|
||
Два параллельных механизма поиска провайдеров контента:
|
||
|
||
**DHT provide/lookup (Kademlia):**
|
||
|
||
- Узел хранящий контент app_id публикует запись "я провайдер для app_id X" в Kademlia DHT
|
||
- Запрашивающий узел делает lookup по app_id, получает список провайдеров
|
||
- Подключается к провайдерам, запрашивает контент через ContentRequest/ChunkRequest
|
||
- Стандартный libp2p content routing
|
||
|
||
**Gossip announce:**
|
||
|
||
- При установлении соединения с новым пиром узел в handshake объявляет список своих app_id (Bloom filter если список большой)
|
||
- Пир запоминает привязку пир → app_id
|
||
- При локальном ContentRequest по app_id которого нет — пересылает запрос пирам объявившим этот app_id
|
||
|
||
Оба механизма работают параллельно. Узел использует любой рабочий путь. Content Discovery — локальная network state, не входит в consensus.
|
||
|
||
#### Genesis Content
|
||
|
||
Книга Montana — первый и обязательный контент сети, зафиксированный в Genesis Decree:
|
||
|
||
```
|
||
genesis_content_app_id = SHA-256("mt-app" || "montana")
|
||
genesis_content_data_hash = <хэш манифеста книги Montana v1.0, хардкодировано в Genesis Decree>
|
||
```
|
||
|
||
**Mandatory replication.** Каждый узел Montana обязан хранить текущую версию книги Montana как persistent blob. Это часть протокольного определения "узел Montana", не optional подписка. При Fast Sync новый узел загружает genesis content вместе с initial state; без успешной загрузки sync считается неполным.
|
||
|
||
**Обновление книги.** Автор публикует новый Anchor в `genesis_content_app_id` с новым `data_hash`. Узлы получают новую версию через Content Request Protocol, верифицируют через Merkle reconstruction, заменяют локальную копию. Старые версии остаются доступными через исторические Anchor в proposals навсегда — версии книги историчны и неудаляемы. Обновление значения `genesis_content_data_hash` в protocol_params возможно только через software upgrade узла (новая версия Rust core с обновлённой константой), как любое изменение Genesis Decree.
|
||
|
||
### Application Layer Interop Standards
|
||
|
||
Этот раздел фиксирует минимальные стандарты для совместимости между приложениями Montana. Приложения следующие этим стандартам могут взаимодействовать между собой — обмениваться профилями, сообщениями, контентом. Приложения использующие другие форматы работают в изоляции.
|
||
|
||
Это нормативный раздел: форматы и формулы в нём обязательны для interop-совместимых приложений.
|
||
|
||
#### Canonical app_id registry
|
||
|
||
Фиксированные app_id для стандартных функций приложений:
|
||
|
||
| Функция | Формула | Назначение |
|
||
|---|---|---|
|
||
| genesis content | `SHA-256("mt-app" \|\| "montana")` | Книга Montana и её обновления |
|
||
| profile | `SHA-256("mt-app" \|\| "profile")` | Публичные профили пользователей |
|
||
| encryption keys | `SHA-256("mt-app" \|\| "encryption-keys")` | Discovery encryption pubkeys |
|
||
| messenger prekeys | `SHA-256("mt-app" \|\| "messenger-prekeys")` | Pre-keys bundles для Double Ratchet |
|
||
| phone discovery | `SHA-256("mt-app" \|\| "phone-discovery")` | Public mode phone → account lookup |
|
||
|
||
Пользовательские каналы используют формулу `SHA-256("mt-app" || channel_name)` где `channel_name` — произвольная строка выбранная создателем канала. Уникальность каналов обеспечивается через уникальность имени; коллизии разрешаются по первому cemented Anchor в данном app_id.
|
||
|
||
#### ProfileBlob format
|
||
|
||
Канонический формат публичного профиля пользователя:
|
||
|
||
```
|
||
ProfileBlob {
|
||
version u16 (currently 1)
|
||
display_name string (UTF-8, length-prefixed, max 64 bytes, may be empty)
|
||
avatar_hash 32B (ref to image blob by data_hash, или 0x00..00)
|
||
bio string (UTF-8, length-prefixed, max 256 bytes, may be empty)
|
||
updated_at u64 (unix timestamp публикации)
|
||
}
|
||
```
|
||
|
||
Сериализация: little-endian, length-prefix для строк (u16 length + bytes).
|
||
|
||
**Публикация профиля:**
|
||
|
||
1. Serialize ProfileBlob канонически
|
||
2. `data_hash = SHA-256("mt-profile" || serialized)`
|
||
3. `store_blob(app_id_profile, data_hash, serialized)`
|
||
4. `publish_anchor(app_id_profile, data_hash)`
|
||
|
||
**Lookup профиля другого пользователя:**
|
||
|
||
1. Запросить через Anchor history: все Anchor с `app_id = profile` и `sender = target_account_id`
|
||
2. Отсортировать по времени (окно финализации Anchor), взять новейший
|
||
3. `fetch_blob(app_id_profile, latest_data_hash)`
|
||
4. Deserialize
|
||
|
||
Profile опционален — пользователь может не публиковать профиль. Приложение должно поддерживать локальные override имён независимо от публичного профиля (пользователь может видеть контакт как "Мама" локально, даже если публичный профиль контакта другой).
|
||
|
||
#### Published encryption_pubkey format
|
||
|
||
Формат блока публикации encryption key пользователя для приёма зашифрованного контента:
|
||
|
||
```
|
||
EncryptionKeyBlob {
|
||
version u16 (currently 1)
|
||
algorithm u16 (1 = ML-KEM-768)
|
||
encryption_pubkey variable (1184B для ML-KEM-768)
|
||
published_at u64 (unix timestamp)
|
||
}
|
||
```
|
||
|
||
**Публикация:**
|
||
|
||
1. Serialize EncryptionKeyBlob
|
||
2. `data_hash = SHA-256("mt-encryption-key" || serialized)`
|
||
3. `store_blob(app_id_encryption_keys, data_hash, serialized)`
|
||
4. `publish_anchor(app_id_encryption_keys, data_hash)`
|
||
|
||
**Lookup encryption key получателя:**
|
||
|
||
1. Запросить Anchor history: все Anchor с `app_id = encryption-keys` и `sender = target_account_id`
|
||
2. Взять новейший (последняя ротация ключа)
|
||
3. `fetch_blob(app_id_encryption_keys, latest_data_hash)`
|
||
4. Deserialize, извлечь encryption_pubkey
|
||
|
||
**Key rotation.** Публикация нового Anchor с новой EncryptionKeyBlob. Старые ключи остаются в proposal history навсегда — старые ciphertexts расшифровываются если владелец сохранил старый seckey.
|
||
|
||
#### Messenger pre-keys bundle format
|
||
|
||
Для инициализации Double Ratchet PQ session с offline получателем. Пользователь публикует pre-keys bundle заранее; отправитель использует его для первого сообщения без ответа получателя.
|
||
|
||
```
|
||
PreKeyBundle {
|
||
version u16 (currently 1)
|
||
identity_key variable (ML-KEM-768 identity pubkey, 1184B)
|
||
signed_prekey variable (ML-KEM-768 signed pre-key, 1184B)
|
||
prekey_signature 666B (FN-DSA-512 подпись signed_prekey identity key)
|
||
one_time_prekeys [variable] (массив ML-KEM-768 pubkeys, одноразовые)
|
||
published_at u64
|
||
}
|
||
```
|
||
|
||
**Публикация:**
|
||
|
||
1. Serialize PreKeyBundle
|
||
2. `data_hash = SHA-256("mt-prekeys" || serialized)`
|
||
3. `store_blob(app_id_messenger_prekeys, data_hash, serialized)`
|
||
4. `publish_anchor(app_id_messenger_prekeys, data_hash)`
|
||
|
||
**Refresh.** При исчерпании one_time_prekeys (каждое pre-key используется одним отправителем и удаляется) публикуется новый bundle. Получатель должен мониторить использование pre-keys и публиковать fresh bundle заранее.
|
||
|
||
#### Phone discovery (public mode)
|
||
|
||
Опциональная функция для приложений поддерживающих поиск по номеру телефона.
|
||
|
||
**Формула:** `phone_hash = SHA-256("mt-phone-public" || phone_e164)`
|
||
|
||
Где `phone_e164` — номер телефона в формате E.164 (например `+79991234567`).
|
||
|
||
**Публикация в public mode:**
|
||
|
||
1. Пользователь явно включил public phone discovery в приложении
|
||
2. Приложение вычисляет phone_hash
|
||
3. `data_hash = phone_hash`
|
||
4. Persistent blob содержит `account_id` владельца (32B)
|
||
5. `store_blob(app_id_phone_discovery, data_hash, account_id)`
|
||
6. `publish_anchor(app_id_phone_discovery, data_hash)`
|
||
|
||
**Lookup:**
|
||
|
||
1. Приложение для каждого контакта из адресной книги вычисляет phone_hash
|
||
2. `fetch_blob(app_id_phone_discovery, phone_hash)` → account_id или not_found
|
||
3. Если найден — контакт в сети Montana
|
||
|
||
**Privacy warning.** Public mode подвержен rainbow table attack. Атакующий со списком phone numbers может вычислить phone_hashes и искать совпадения в сети. Это эквивалентно модели WhatsApp. Пользователь выбирает режим осознанно.
|
||
|
||
**Private mode** (рекомендованный по умолчанию). Пользователь не публикует phone_hash. Контакты добавляются только через QR-код, ссылку или прямой обмен account_id. Максимальная приватность, ручной ввод контактов.
|
||
|
||
#### Recommended crypto primitives для Application Layer
|
||
|
||
Эти примитивы **не входят** в protocol core (core остаётся с SHA-256 + FN-DSA-512). Они рекомендованы для Application Layer encryption и messaging чтобы обеспечить совместимость между приложениями. Приложения использующие другие примитивы работают в изоляции.
|
||
|
||
| Примитив | Стандарт | Применение |
|
||
|---|---|---|
|
||
| ML-KEM-768 | FIPS 203, NIST PQC | Key encapsulation для encrypted messaging и file encryption |
|
||
| ChaCha20-Poly1305 | RFC 8439 | Symmetric AEAD encryption содержимого |
|
||
| HKDF-SHA-256 | RFC 5869 | Derivation ключей из KEM shared secret |
|
||
|
||
Все три примитива постквантово-безопасны или симметричны (ChaCha20-Poly1305 ослабляется Grover до 128-bit, приемлемо). Production-ready реализации доступны для всех major языков.
|
||
|
||
**Application-level key derivation из seed.** Encryption keypair (ML-KEM-768) выводится из того же seed что и account и node keypairs, через отдельный domain separator `mt-encryption-key` (см. раздел Деривация ключей). Восстановление seed из мнемоники восстанавливает все три keypair одной операцией.
|
||
|
||
### Integration
|
||
|
||
Три операции для подключения внешних систем к Montana.
|
||
|
||
#### Write — запись
|
||
|
||
Внешняя система формирует Anchor и отправляет в P2P-сеть.
|
||
|
||
```
|
||
Вход: app_id (32B) + data_hash (32B) + подпись FN-DSA-512
|
||
Выход: Anchor финализирован в окне W через ≥67% active_chain_length
|
||
confirmations с timechain_value T_W
|
||
```
|
||
|
||
data_hash — произвольный хэш: Merkle root документов, хэш batch'а Rollup, fingerprint состояния. Montana не интерпретирует содержимое — хранит 32 байта с привязкой ко времени.
|
||
|
||
#### Read — сбор proof
|
||
|
||
Внешняя система собирает timestamp proof в момент финализации Anchor.
|
||
|
||
```
|
||
Вход: Anchor (только что финализированный)
|
||
Выход: Anchor body + BundledConfirmations покрывающие H(Anchor) +
|
||
proposal header окна cementing'а + цепочка proposal headers до genesis
|
||
```
|
||
|
||
Сбор proof — клиентская задача. После получения BundledConfirmations с суммарным chain_length ≥ quorum клиент сохраняет proof локально. Узлы Montana не обязаны хранить BundledConfirmations долгосрочно — они нужны только для текущего подсчёта quorum.
|
||
|
||
#### Verify — верификация
|
||
|
||
Внешняя система проверяет proof автономно, без доверия к Montana-узлу.
|
||
|
||
```
|
||
1. Если есть Merkle path: пересчитать H(D) → data_hash в Anchor
|
||
2. Проверить FN-DSA-512 подпись на Anchor
|
||
3. Для каждой BundledConfirmation в proof:
|
||
a. Проверить FN-DSA-512 подпись confirmer
|
||
b. Пересчитать NodeChain endpoint confirmer от start_window до окна W
|
||
c. Подтвердить заявленный chain_length
|
||
4. Суммировать chain_length подтверждающих ≥ 67% active_chain_length(W)
|
||
5. Проверить FN-DSA-512 подпись proposer на header окна W
|
||
6. Проверить timechain_value(W) пересчётом TimeChain VDF от T_{W-1}
|
||
7. Проверить цепочку proposals от W до genesis (prev_proposal_hash)
|
||
```
|
||
|
||
Шаги 1, 2, 3a, 5: миллисекунды. Шаг 3b: пересчёт NodeChain VDF confirmer — m × (W − start_window) хэшей, параллелизуется по сегментам. Шаг 6: ~60 секунд на одном ядре (один сегмент TimeChain VDF). Шаг 7: линейная проверка подписей и хэшей по цепочке proposals от окна W до genesis.
|
||
|
||
Полная верификация от генезиса: H сегментов TimeChain VDF, каждый независим. На C ядрах: ~(H/C) × 60 секунд. TimeChain хранит все промежуточные T_r в proposals — параллелизация полная.
|
||
|
||
---
|
||
|
||
## Ключи
|
||
|
||
### Мнемоника и seed
|
||
|
||
24 слова из словаря BIP-39 (2 048 английских слов). 256 бит энтропии + 8 бит checksum.
|
||
|
||
```
|
||
mnemonic: 24 слова BIP-39
|
||
seed: PBKDF2-SHA512(mnemonic, "mt-seed", 2048 итераций)
|
||
```
|
||
|
||
### Деривация
|
||
|
||
```
|
||
seed
|
||
├── Аккаунт: FN-DSA-512 keypair (HMAC-SHA256(seed || "mt-account-key"))
|
||
│ → account_id = SHA-256("mt-account" || account_pubkey)
|
||
└── Узел: FN-DSA-512 keypair (HMAC-SHA256(seed || "mt-node-key"))
|
||
→ node_id = SHA-256("mt-node" || node_pubkey)
|
||
```
|
||
|
||
Один seed порождает два FN-DSA-512 keypair. Аккаунт — подпись операций пользователя. Узел — подпись proposals и NodeChain endpoints. Это полный набор секретных материалов protocol core.
|
||
|
||
account_id и node_id выводятся из публичных ключей, верифицируемы без знания seed.
|
||
|
||
**Application-level keys.** Приложения могут выводить дополнительные ключи из того же seed через свои domain separators (не protocol-critical). Рекомендованный стандарт Application Layer определяет encryption keypair через `HMAC-SHA256(seed || "mt-app-encryption-key")` для ML-KEM-768. Этот ключ не входит в protocol core — его знание не нужно узлам консенсуса. Приложения использующие этот стандарт получают совместимое восстановление: один seed → все ключи (account, node, encryption).
|
||
|
||
Следствие: любое устройство с seed получает полный доступ к аккаунту. Баланс читается из текущего Account Table — никакого локального состояния не требуется. Бэкап = 24 слова, восстановление мгновенное.
|
||
|
||
---
|
||
|
||
## Криптографическая реализация
|
||
|
||
### Primitive layer
|
||
|
||
Собственная реализация криптографических примитивов запрещена. Только audited библиотеки с constant-time гарантиями и опубликованными test vectors.
|
||
|
||
| Примитив | Стандарт | Роль |
|
||
|----------|----------|------|
|
||
| SHA-256 | FIPS 180-4 | TimeChain, NodeChain, адреса, Merkle-деревья |
|
||
| FN-DSA-512 | NIST PQC selection финал (июль 2022), forthcoming FIPS 206, reference implementation production-ready | Подписи операций аккаунтов и proposals узлов |
|
||
|
||
### Consensus encoding layer
|
||
|
||
Консенсусно-критическая поверхность: каноническая сериализация, Merkle layout и domain separation. Разная сериализация одного объекта = разный хэш = форк. Требования:
|
||
|
||
- Fixed binary encoding для каждого консенсусного объекта
|
||
- Length-prefix кодирование полей, фиксированный endianness (little-endian)
|
||
- Domain separation для всех хэшей:
|
||
|
||
| Домен | Контекст |
|
||
|-------|----------|
|
||
| `mt-op` | Хэширование операций аккаунтов |
|
||
| `mt-header` | Хэширование proposal headers |
|
||
| `mt-account` | Деривация account_id |
|
||
| `mt-invitation` | Деривация invitation_id и хэширование NodeInvitation |
|
||
| `mt-merkle-leaf` | Листья Merkle-деревьев |
|
||
| `mt-merkle-node` | Внутренние узлы Merkle-деревьев |
|
||
| `mt-state-root` | Композиция state_root из node_root, invitation_root и account_root |
|
||
| `mt-timechain` | TimeChain VDF seed |
|
||
| `mt-nodechain-init` | NodeChain init seed |
|
||
| `mt-confirmation` | Хэширование async confirmations |
|
||
| `mt-app` | Деривация app_id для Application Layer |
|
||
| `mt-node` | Деривация node_id |
|
||
| `mt-genesis` | Деривация frontier_hash genesis-аккаунтов |
|
||
| `mt-nodechain-genesis` | Деривация nodechain_init для genesis-узлов |
|
||
| `mt-seed` | Salt для PBKDF2 деривации seed из мнемоники |
|
||
| `mt-account-key` | Деривация keypair аккаунта из seed |
|
||
| `mt-node-key` | Деривация keypair узла из seed |
|
||
| `mt-account-lottery` | Endpoint AccountChain для лотереи |
|
||
| `mt-content-chunk` | Хэширование чанков контента в Content Layer |
|
||
| `mt-content-manifest` | Хэширование манифеста чанкованного контента |
|
||
| `mt-profile` | Хэширование ProfileBlob в Application Layer |
|
||
| `mt-encryption-key` | Хэширование EncryptionKeyBlob в Application Layer |
|
||
| `mt-app-encryption-key` | Деривация encryption keypair из seed в Application Layer |
|
||
| `mt-prekeys` | Хэширование PreKeyBundle в Application Layer |
|
||
| `mt-phone-public` | Хэширование phone_hash для public mode phone discovery |
|
||
| `mt-tunnel` | IBT proof подпись при входе на узел |
|
||
| `mt-bootstrap-pow` | Proof-of-work при подключении к bootstrap |
|
||
|
||
- Альтернативные сериализации запрещены
|
||
- Test vectors для каждого консенсусного объекта
|
||
- Cross-implementation conformance tests перед запуском mainnet
|
||
|
||
### Protocol layer
|
||
|
||
Собственная реализация поверх криптографического ядра:
|
||
|
||
| Компонент | Назначение |
|
||
|-----------|------------|
|
||
| Merkle-деревья | State Root (из SHA-256 вызовов) |
|
||
| VDF scheduling | Управление TimeChain и NodeChain цепочками |
|
||
| State machine | Account Table, Node Table, state transitions |
|
||
| P2P gossip | Распространение операций, confirmations и proposals |
|
||
|
||
### Инфраструктура
|
||
|
||
| Библиотека | Назначение |
|
||
|------------|------------|
|
||
| RocksDB | Хранение Account Table и операций |
|
||
| libp2p | P2P транспорт |
|
||
|
||
Production: Rust.
|
||
|
||
---
|
||
|
||
## Сетевой уровень
|
||
|
||
### Transport Obfuscation
|
||
|
||
Монтана — персональная сеть. Каждый узел — персональный сервер участника. Транспортный слой построен из этого определения: персональный сервер отвечает только участникам, персональный мессенджер скрывает тайминг сообщений, персональный = доступный обычному человеку.
|
||
|
||
#### Шифрование
|
||
|
||
Все P2P-соединения инкапсулированы в TLS 1.3 на порт 443. Noise framework (встроен в libp2p) для аутентификации по публичному ключу узла внутри TLS. Содержимое трафика недоступно наблюдателю.
|
||
|
||
#### Identity-Bound Tunnel (IBT)
|
||
|
||
Персональный сервер отвечает только участникам сети. После TLS handshake клиент отправляет proof аутентификации. Узлы (зарегистрированные и приглашённые) подписывают node keypair. Аккаунты (клиенты) подписывают account keypair.
|
||
|
||
```
|
||
proof = FN-DSA-512_sign(client_privkey,
|
||
"mt-tunnel" || server_node_id || floor(unix_timestamp / 120))
|
||
```
|
||
|
||
Сервер проверяет:
|
||
|
||
1. Подпись валидна для заявленного client_pubkey
|
||
2. Timestamp slot = текущий ИЛИ предыдущий (окно 4 минуты)
|
||
3. Уровень доступа — сервер проверяет client_pubkey по трём таблицам последовательно, первое совпадение определяет уровень:
|
||
- `node_id = SHA-256("mt-node" || client_pubkey)` в Node Table → **полный gossip** (клиент подключился node keypair)
|
||
- `invitation_id` с `invited_pubkey = client_pubkey` в Invitation Table → **read-only gossip**: получает proposals, отправляет только свой NodeRegistration (клиент подключился node keypair)
|
||
- `account_id = SHA-256("mt-account" || suite_id || client_pubkey)` в Account Table → **подключение к доверенному узлу** (клиент подключился account keypair)
|
||
- Ни одно не найдено → отказ
|
||
|
||
Условия 1-2 выполнены + уровень 3 определён → Noise handshake → Montana P2P с соответствующим уровнем доступа.
|
||
Любое не выполнено → TLS alert `bad_certificate`, close. Стандартное поведение сервера с обязательной аутентификацией клиента — таких серверов в интернете миллионы (корпоративные порталы, API, банковские системы).
|
||
|
||
Replay protection: server_node_id привязывает proof к конкретному получателю. Timestamp slot ограничивает окно до 4 минут.
|
||
|
||
Bootstrap exception: genesis bootstrap nodes хардкодированы как `(IP, node_id, pubkey) × 12`. Bootstrap принимает proof от любого валидного FN-DSA-512 ключа (Account Table не проверяется). Для защиты от connection flood клиент прилагает proof-of-work:
|
||
|
||
```
|
||
SHA-256("mt-bootstrap-pow" || proof || nonce) < target
|
||
```
|
||
|
||
`target` подбирается чтобы стоимость ≈ 100ms CPU. PoW требуется только при подключении к bootstrap, не к обычным peers.
|
||
|
||
#### Uniform Framing
|
||
|
||
Все Montana-сообщения внутри IBT-соединения фрагментируются на фреймы фиксированного размера:
|
||
|
||
```
|
||
frame_size = 1024 bytes
|
||
|
||
frame format:
|
||
flags 1B (0x01 = data, 0x02 = padding, 0x04 = continuation)
|
||
length 2B (полезная нагрузка, ≤1021B)
|
||
payload 1021B (данные или random padding до frame_size)
|
||
```
|
||
|
||
Персональный мессенджер скрывает тайминг: между узлами идёт постоянный поток фреймов. Реальные Montana-сообщения замещают padding-фреймы, не добавляются к ним. Наблюдатель внутри сети не может отличить перевод от доказательства времени от тишины — всё одинаковые зашифрованные фреймы.
|
||
|
||
Параметры:
|
||
|
||
- Baseline frame rate: 1 frame/сек на исходящих соединениях. Входящие — фреймы при наличии данных
|
||
- Maximum burst: ≤ 8 frames подряд без паузы ≥ 10ms
|
||
- Minimum padding ratio: ≥ 20% фреймов в скользящем 60-секундном окне на исходящих
|
||
|
||
Персональный = доступный: 8 исходящих × 1 frame/сек × 1024 bytes = 8 KB/сек ≈ 20 GB/мес. Приемлемо для домашнего сервера.
|
||
|
||
#### Transport Randomness
|
||
|
||
Все рандомизированные решения транспортного уровня (stem routing, frame scheduling, nonce generation) используют CSPRNG из OS entropy pool. Детерминированный PRNG от node state запрещён для transport-layer randomness.
|
||
|
||
Transport obfuscation ортогонален консенсусу. TimeChain, NodeChain, state machine работают поверх любого транспорта без изменений.
|
||
|
||
### Peer Selection
|
||
|
||
Приватная сеть по приглашениям делает sybil-узлы дорогими: каждый sybil = приглашение + 14 дней VDF + выделенное ядро CPU. Peer selection использует эту особенность — diversity constraints из протокольных данных (start_window, inviter) дополняют сетевые (/16, ASN).
|
||
|
||
P2P gossip — только зарегистрированные и приглашённые узлы (уровни 1-2 IBT, см. Transport Obfuscation → Identity-Bound Tunnel). Аккаунты (уровень 3 IBT) взаимодействуют через свой доверенный узел.
|
||
|
||
#### Исходящие соединения
|
||
|
||
8 исходящих, все полные. Uniform framing скрывает типы сообщений — отдельные relay-only соединения не нужны.
|
||
|
||
Выбор: случайный 50/50 из таблиц «новые» и «проверенные» (модель addrman Bitcoin Core). Бакетирование с секретным ключом узла. Без preference по chain_length — выбор равномерный.
|
||
|
||
#### Четыре уровня diversity
|
||
|
||
Каждый исходящий проверяется по всем четырём constraints:
|
||
|
||
```
|
||
Сетевые:
|
||
/16 — не более 1 исходящего на /16 подсеть (IPv4) или /48 (IPv6)
|
||
ASN — не более 2 исходящих на автономную систему
|
||
|
||
Протокольные:
|
||
start_window — не более 2 исходящих к узлам с start_window в одном τ₂
|
||
inviter — не более 2 исходящих к узлам приглашённым одним inviter
|
||
```
|
||
|
||
Сетевые constraints — доказаны 10 годами Bitcoin Core (Heilman et al. 2015 → netgroup diversity → ASMAP). Протокольные constraints — уникальны для приватной сети: start_window и inviter_node_id канонически доступны из Node Table и proposal history.
|
||
|
||
Следствие: кластер sybil от одного inviter → максимум 2 из 8 слотов. Кластер sybil зарегистрированных в один τ₂ → максимум 2 из 8. Eclipse требует минимум 4 независимых inviter в 4 разных AS в 4 разных /16 с регистрацией в 4 разных τ₂.
|
||
|
||
ASN-карта загружается при запуске (аналог ASMAP Bitcoin Core). Без карты — fallback на /16.
|
||
|
||
#### Адресный менеджер
|
||
|
||
Две таблицы:
|
||
|
||
- **Новые** — адреса полученные через peer exchange и DHT. Узел ещё не подключался
|
||
- **Проверенные** — адреса к которым узел успешно подключался через IBT
|
||
|
||
Бакетирование: `bucket = Hash(secret_key, source_group, addr_group) % N`. Детерминированно с секретным ключом — атакующий не может предсказать в какой бакет попадёт его адрес.
|
||
|
||
#### Входящие соединения
|
||
|
||
До 32 входящих. При переполнении — вытеснение:
|
||
|
||
1. Защитить 4 с наименьшим пингом
|
||
2. Защитить 4 с последними полезными сообщениями (любое валидное Montana-сообщение которое узел ещё не видел)
|
||
3. Защитить до 8 из разных подсетей (по одному от каждой)
|
||
4. Защитить 4 с последними proposals
|
||
5. Из оставшихся — вытеснить из крупнейшей подсетевой группы
|
||
|
||
#### Якоря
|
||
|
||
2 исходящих с наибольшим uptime соединения сохраняются каждые τ₂. При перезапуске после аварии или обновления — подключиться к якорям первым до случайного выбора из таблиц.
|
||
|
||
#### Feeler
|
||
|
||
Каждые 10 минут: подключиться к случайному адресу из «новых», выполнить IBT handshake (все три уровня проверки). Успех на любом уровне → перенести в «проверенные» с пометкой уровня (node / invited / account). Неуспех → пометить или удалить.
|
||
|
||
#### Ротация
|
||
|
||
По поведению: если peer не передал ни одного нового proposal за τ₂ — заменить. Peer с долей невалидных сообщений выше 50% в скользящем τ₁-окне — отключить с запретом переподключения на τ₂. Peer который relay-ит честно — полезен сети, остаётся.
|
||
|
||
#### PeerRecord
|
||
|
||
Формат записи о пире при peer exchange:
|
||
|
||
```
|
||
PeerRecord:
|
||
ip 16B (IPv4-mapped IPv6)
|
||
port 2B (u16)
|
||
node_id 32B
|
||
node_pubkey 897B (FN-DSA-512)
|
||
```
|
||
|
||
Без node_id и node_pubkey клиент не может вычислить IBT proof для подключения. Peer exchange: не более 100 PeerRecord за сообщение. Не более 1 peer exchange сообщения в минуту от каждого peer.
|
||
|
||
### Censorship-Resistant Discovery
|
||
|
||
Генезис: 12 hardcoded bootstrap nodes `(IP, node_id, pubkey)`. Если все 12 IP заблокированы на уровне страны — новый узел не может войти в сеть. Четыре независимых канала обнаружения. Достаточно одного из четырёх.
|
||
|
||
**1. Peer exchange.** Каждый узел хранит и передаёт список активных пиров новичкам. Достаточно знать IP одного узла — друг, QR-код, мессенджер. Один живой контакт = вход в сеть.
|
||
|
||
**2. DHT.** Kademlia DHT поверх libp2p. Узлы находят друг друга без центральной точки. Идентификаторы рандомизированы — DHT не раскрывает node_id до установления Montana-соединения.
|
||
|
||
**3. Bridge nodes.** Узлы за пределами цензурируемой юрисдикции, опубликованные через внеполосные каналы (социальные сети, мессенджеры, печатные QR-коды). IP bridge node неизвестен фаерволу до использования.
|
||
|
||
**4. Encrypted Client Hello (ECH).** Bootstrap через CDN с поддержкой ECH. SNI зашифрован — наблюдатель видит IP CDN, но не целевой домен. Эффективен в юрисдикциях без активной блокировки ECH extension. В юрисдикциях блокирующих ECH (Китай с 2023, Россия с 2024) — канал неработоспособен. Для таких юрисдикций — каналы 1-3.
|
||
|
||
Избыточность = устойчивость. Четыре канала независимы. Блокировка одного не влияет на остальные.
|
||
|
||
### Dandelion++ (анонимность отправителя)
|
||
|
||
P2P gossip Montana ретранслирует операции через все узлы. Без защиты первый пир знает IP отправителя. Dandelion++ (Fanti et al. 2018) устраняет связь IP → операция модификацией существующего gossip.
|
||
|
||
**Две фазы:**
|
||
|
||
```
|
||
Stem (стебель):
|
||
Операция проходит по цепочке случайных узлов (в среднем 2-3 hop).
|
||
Каждый узел видит только предыдущий hop, не автора.
|
||
На каждом hop с вероятностью p = 0.4 переход в fluff.
|
||
E[stem_length] = 1/p = 2.5 hops.
|
||
P(stem ≤ 1) = 40%, P(stem ≤ 3) = 78%.
|
||
|
||
Fluff (пух):
|
||
Последний stem-узел запускает обычный gossip.
|
||
Для всей сети операция «появилась» из случайной точки.
|
||
```
|
||
|
||
**Stem routing.** Стебель использует только исходящие соединения — входящие не участвуют. Каждые 1440 окон (~24 часа) узел выбирает 2 из 8 исходящих как стебельных (stem epoch = 1 день). Все стебельные операции в эпохе направляются через одного из этих 2 (выбор по hash(msg)).
|
||
|
||
**Применение по типу объекта:**
|
||
|
||
| Объект | Режим | Причина |
|
||
|--------|-------|---------|
|
||
| UserObject (Transfer, Anchor, OpenAccount, ChangeKey) | Stem → fluff | Скрыть IP отправителя |
|
||
| ControlObject (NodeInvitation, NodeRegistration) | Stem → fluff | Скрыть IP пригласившего/регистрирующегося |
|
||
| VDF Reveal | Прямой gossip (без stem) | node_id публичен в reveal, анонимность невозможна |
|
||
| Confirmation | Stem → fluff | Скрыть какой узел подтвердил первым |
|
||
|
||
VDF Reveal — единственное исключение. Reveal содержит node_id по определению. Связь IP → node_id для внешнего наблюдателя закрыта слоем Transport Obfuscation (TLS 1.3 на порт 443).
|
||
|
||
**Свойства:**
|
||
|
||
| Угроза | Защита |
|
||
|--------|--------|
|
||
| Пир видит IP отправителя | Stem: пир видит только предыдущий hop |
|
||
| Глобальный наблюдатель (ISP) | TLS 1.3 + uniform framing (Transport Obfuscation) |
|
||
| Анализ графа gossip | Операция входит в gossip из случайной точки |
|
||
| Контроль k узлов | Деанонимизация требует контроля O(√n) узлов |
|
||
|
||
**Реализация:**
|
||
|
||
```
|
||
stem_peers = random_sample(outbound, 2) // каждые 1440 окон
|
||
|
||
on_receive_stem(msg, from_peer):
|
||
if random() < 0.4:
|
||
gossip_broadcast(msg) // fluff
|
||
else:
|
||
next = stem_peers[hash(msg) % 2] // детерминированный выбор из 2
|
||
send_stem(msg, next) // продолжить stem
|
||
start_timer(msg, 30s) // страховка на каждом hop
|
||
|
||
on_timer_expired(msg):
|
||
if msg не обнаружен в gossip:
|
||
gossip_broadcast(msg) // принудительный fluff
|
||
```
|
||
|
||
Каждый stem-узел страхует следующий. Таймер 30 секунд на каждом hop независимо. Если следующий hop уронил сообщение — текущий hop обнаруживает отсутствие операции в gossip и делает fluff сам. Максимальная задержка = 30 секунд (один hop), не кумулятивная.
|
||
|
||
Dandelion++ не требует внешней инфраструктуры. Каждый Montana-узел уже является relay — gossip существует, stem добавляет 2-3 hop перед ним. Latency overhead: миллисекунды.
|
||
|
||
### NAT Traversal
|
||
|
||
Персональная сеть работает когда каждый может войти. Большинство домашних пользователей за NAT — невидимы для входящих соединений. Без NAT traversal персональный интернет = серверный клуб.
|
||
|
||
Три механизма, каждый следующий — если предыдущий не сработал:
|
||
|
||
**1. AutoNAT (определение).** Узел спрашивает outbound peers: «видишь ли мой IP:port напрямую?» Если да — NAT нет. Если нет — узел знает свой NAT-статус.
|
||
|
||
**2. DCUtR (пробивка).** Два NAT-узла координируются через третий узел с публичным IP. Оба отправляют исходящие пакеты — роутеры открывают «дырки» для ответов. После координации — прямое соединение. Успех: 60-70% случаев (TCP). Carrier-grade NAT (мобильные операторы): ~30%.
|
||
|
||
**3. Circuit Relay v2 (транзит).** Если пробивка не удалась — трафик идёт через outbound peer с публичным IP. Relay — не отдельный механизм и не выделенный сервер. Relay-соединение = обычное исходящее соединение, подчиняющееся тем же правилам: uniform framing, diversity constraints, ротация по поведению. Содержимое зашифровано конец-в-конец (Noise) — relay видит IP участников но не содержимое. Metadata распределён по 8 outbound peers из разных /16 и ASN — ни один relay не видит полный граф.
|
||
|
||
Relay — не fallback а гарантия подключения при любом типе NAT. Пробивка — оптимизация для снижения нагрузки на relay.
|
||
|
||
**Лимиты relay:** до 32 одновременных relay-соединений на узел, bandwidth per relay ≤ baseline frame rate (1 KB/сек). 32 × 1 KB/сек = 32 KB/сек ≈ 82 GB/мес — приемлемо для домашнего узла с публичным IP.
|
||
|
||
**Обязанность.** Узлы с публичным IP поддерживают relay — персональная сеть работает когда каждый может войти. Reference implementation включает relay при обнаружении публичного IP. Feeler-подключения проверяют поддержку relay у peers; узлы без relay помечаются `no-relay` в адресном менеджере. NAT-узлы предпочитают peers поддерживающие relay при выборе исходящих.
|
||
|
||
Все три механизма — стандарт libp2p (AutoNAT, DCUtR, Circuit Relay v2). Ноль новых протокольных примитивов.
|
||
|
||
### Пять слоёв — одна конструкция
|
||
|
||
```
|
||
Слой 1: Transport Obfuscation персональный сервер скрывает содержимое и тайминг
|
||
Слой 2: Peer Selection invitation-aware diversity не даёт окружить узел
|
||
Слой 3: NAT Traversal каждый может войти, даже за NAT
|
||
Слой 4: Censorship-Resistant Discovery четыре канала, достаточно одного
|
||
Слой 5: Dandelion++ пиры не знают кто автор операции
|
||
```
|
||
|
||
Каждый слой закрывает свой вектор. Ни один не требует внешней инфраструктуры. Всё построено поверх libp2p и существующего gossip. Сетевой уровень ортогонален консенсусу — ни один state transition не затронут.
|
||
|
||
---
|
||
|
||
## Эволюция протокола
|
||
|
||
Протокол Montana не имеет on-chain governance. Изменения правил протокола не голосуются внутри консенсуса, не подписываются советами, не хранятся в state. Эволюция проходит по той же модели что Bitcoin: открытые предложения, независимые реализации, добровольный выбор операторов узлов, fork resolution через большинство chain_length.
|
||
|
||
### Принцип
|
||
|
||
Consensus state Montana содержит только то что необходимо для финансового слоя и хронометража: TimeChain, NodeChain, AccountChain, Account Table, Node Table. Никаких полей governance, никаких советов в state, никаких голосований в реестре операций. Любая попытка ввести on-chain governance вводит subjective компоненты в consensus state и создаёт постоянную атакуемую поверхность — это нарушение глобального инварианта I-3.
|
||
|
||
Эволюция протокола существует **вне** consensus state, как социальный и инженерный процесс над Content Layer и репозиториями реализаций.
|
||
|
||
### Жизненный цикл изменения
|
||
|
||
```
|
||
1. PROPOSAL
|
||
Любой участник публикует MIP (Montana Improvement Proposal)
|
||
как persistent blob в Content Layer:
|
||
app_id = SHA-256("mt-app" || "mips")
|
||
data_hash = H(текст MIP)
|
||
anchor = операция Anchor в AccountChain автора
|
||
|
||
Авторство и timestamp доказуемы через подпись Anchor и
|
||
timechain_value cemented окна. История эволюции навсегда
|
||
в Content Layer + TimeChain.
|
||
|
||
2. DISCUSSION
|
||
Открытое обсуждение в публичных каналах
|
||
(форумы, репозитории, advisory councils — см. ниже).
|
||
Никаких формальных голосований внутри протокола.
|
||
|
||
3. IMPLEMENTATION
|
||
Реализации (Rust core и альтернативные клиенты) выпускают
|
||
новые версии узлового ПО с реализованным изменением.
|
||
Каждая версия закрепляется за конкретным protocol_version
|
||
(u32 в Proposal header).
|
||
|
||
4. ADOPTION
|
||
Операторы узлов самостоятельно выбирают какую версию
|
||
запускать. Никакого on-chain голосования, никакого формального
|
||
activation window. Узлы публикуют proposals со своим protocol_version.
|
||
|
||
5. FORK RESOLUTION
|
||
При расхождении правил сеть может разделиться на цепочки.
|
||
Каждый узел следует той цепочке которая длиннее по его
|
||
собственным правилам валидации (chain_length majority).
|
||
Меньшинство либо обновляется до правил большинства, либо
|
||
продолжает работать как независимая цепочка (hard fork).
|
||
```
|
||
|
||
### Поле protocol_version
|
||
|
||
Поле `protocol_version` (u32) в Proposal header — единственный сигнал эволюции внутри консенсуса. Узел публикует proposals с тем `protocol_version` который реализован его версией ПО. Инвариант `protocol_version >= prev_proposal.protocol_version` запрещает откат к более старым правилам внутри одной цепочки.
|
||
|
||
`protocol_version` не голосуется и не активируется через governance. Он отражает фактическое состояние реализации узла — что узел реально умеет валидировать. Расхождение `protocol_version` между honest узлами разрешается естественно через fork choice по chain_length.
|
||
|
||
### Advisory councils
|
||
|
||
Группы экспертов могут существовать как **advisory** структуры — публикующие рекомендации, обзоры, анализ безопасности через Content Layer. Их подписи не имеют binding эффекта на consensus, их составы не хранятся в state, их голоса не считаются в state transitions.
|
||
|
||
Примеры advisory структур (опциональны, не часть протокола):
|
||
|
||
- **AI Council** — модели разных компаний публикуют технические обзоры MIPs
|
||
- **Core Council** — публичные эксперты публикуют анализ безопасности и социальную координацию
|
||
|
||
Захват advisory совета не даёт контроля над протоколом — он даёт только возможность опубликовать рекомендацию, которую операторы узлов могут проигнорировать. Это устраняет attack surface governance: нет binding голосования = нет цели для компрометации.
|
||
|
||
Advisory councils организуются вне протокола (репозитории, форумы, каналы Content Layer). Протокол не знает об их существовании и не выделяет им никаких прав.
|
||
|
||
### Сравнение с Bitcoin
|
||
|
||
Модель полностью симметрична Bitcoin BIP процессу:
|
||
|
||
| Bitcoin | Montana |
|
||
|---------|---------|
|
||
| BIP в репозитории bitcoin/bips | MIP в Content Layer |
|
||
| Core devs выпускают bitcoind | Core devs выпускают Rust core |
|
||
| Майнеры выбирают версию | Узлы выбирают версию |
|
||
| Hash power voting (фактическое) | chain_length voting (фактическое) |
|
||
| Hard fork → две цепи | Hard fork → две цепи |
|
||
| Нет on-chain governance | Нет on-chain governance |
|
||
|
||
Bitcoin работает по этой модели 16 лет без on-chain governance. Это не эксперимент, а проверенная временем архитектура. Montana следует тому же принципу.
|
||
|
||
### Параметрическая калибровка
|
||
|
||
Параметры D, m, R, F калибруются автоматически по канонической формуле каждые τ₂ — это **не** governance. Калибровка детерминирована, опирается только на consensus state, не требует голосования и не требует социальной координации. Любая правка самой формулы калибровки требует MIP + новой версии ПО + adoption через chain_length, как и любое другое изменение протокола.
|
||
|
||
---
|
||
|
||
## Архитектура
|
||
|
||
```
|
||
ТЕЛЕФОН / ДЕСКТОП УЗЕЛ (десктоп / сервер, 24/7)
|
||
┌────────────────────────┐ ┌──────────────────────────────────────┐
|
||
│ Кошелёк │ │ │
|
||
│ FN-DSA-512 keypair │ │ TimeChain │
|
||
│ локальная UX-история │ │ T_r = SHA-256^D(T_{r-1}) │
|
||
│ операций │ │ глобальные часы, источник │
|
||
│ │ │ случайности │
|
||
│ AccountChain │ │ │ │
|
||
│ (счётчик окон │ │ ▼ │
|
||
│ активности) │ │ NodeChain (per node) │
|
||
│ │ │ S_{i,w} = SHA-256(S_{i,w-1} || T_w │
|
||
└──────────┬─────────────┘ │ || node_id) │
|
||
│ операции │ доказательство присутствия │
|
||
│ (type|prev_hash| │ chain_length = окна с BundledConf. │
|
||
│ payload|FN-DSA-512) │ │ │
|
||
└──────────────────────▶│ ▼ │
|
||
confirmations │ AccountTable │
|
||
◀──────────────────-│ balance: u64 (открыт) │
|
||
│ pubkey, frontier_hash │
|
||
│ account_chain_length │
|
||
│ │ │
|
||
│ ▼ │
|
||
│ Proposals (навсегда) │
|
||
│ control_root, node_root, │
|
||
│ account_root, timechain_value │
|
||
└──────────────────────────────────────┘
|
||
|
||
Зависимости: TimeChain → NodeChain → AccountTable
|
||
Отказ AccountTable не останавливает часы.
|
||
Отказ узла не заражает TimeChain.
|
||
```
|