2451 lines
213 KiB
Markdown
2451 lines
213 KiB
Markdown
# Montana — Спецификация протокола
|
||
|
||
**Версия:** 28.0.6 (2026-04-14)
|
||
|
||
## Определение
|
||
|
||
Montana — персональный P2P интернет на протоколе времени. Защищённое хранение данных, приватная связь и монеты времени — на узле пользователя.
|
||
|
||
Протокол Montana — фундамент персонального интернета. Сеть независимых VDF-осцилляторов, производящая каноническую последовательность событий через последовательное хэширование и консенсус между узлами. Каждое канонически зарегистрированное окно = 13 Ɉ (TimeCoin).
|
||
|
||
**Montana Time** — реляционная структура, конституируемая последовательным хэшированием в рамках VDF и канонической упорядоченностью, устанавливаемой консенсусом между узлами. Внутри этой структуры время в протоколе существует как последовательность канонических событий. Montana — самодостаточная система отсчёта: каноническая последовательность событий, которую внешние системы могут наблюдать и использовать как reference frame для своих нужд.
|
||
|
||
### Три проблемы доверия
|
||
|
||
Montana решает три проблемы, каждая без участия третьей стороны:
|
||
|
||
- **Доверие ко времени.** Протокол производит каноническую последовательность событий без внешних источников. Решено протокольным слоем: VDF, consensus, window_index.
|
||
- **Доверие к хранению.** Данные пользователя хранятся на его узле. Протокол предоставляет фундамент: identity (account_id), фиксация (Anchor — 32 байта хэш навсегда), стимул держать узел online (лотерея, TimeCoin). Хранение, шифрование, индексация — клиентский слой.
|
||
- **Доверие к коммуникации.** Связь между пользователями идёт через их узлы, без центрального посредника. Протокол предоставляет: P2P сеть, identity, постквантовое шифрование (ML-KEM). Мессенджер, discovery, профили — клиентский слой.
|
||
|
||
### Четыре слоя персонального интернета
|
||
|
||
Протокол и клиентский слой вместе образуют четыре слоя:
|
||
|
||
**1. Агент-посредник.** ИИ-агент (Juno) действует строго от имени пользователя. Фильтрует и приоритизирует информацию по критериям владельца, не по алгоритмам платформы. Может ходить во внешний интернет, собирать данные, но решения о фильтрации принадлежат человеку. *Реализация: клиентский слой (app spec).*
|
||
|
||
**2. Локальное хранилище знаний.** Всё что пользователь читал, сохранял, получал — индексировано, доступно для поиска, хранится на его узле. Не на серверах корпорации. Контекст накапливается со временем — персональная база знаний. Протокол фиксирует факт существования (Anchor = 32B хэш). Содержание — на узле владельца, зашифровано его ключом. *Реализация: протокол (Anchor, identity) + клиентский слой (хранение, индексация, поиск).*
|
||
|
||
**3. Управление вниманием.** Персональный интернет не максимизирует время пользователя в системе, а минимизирует его. Дал нужное — отпустил. Нет алгоритмической ленты, нет рекламы, нет engagement metrics, нет autoplay. Бизнес-модель Montana — эмиссия через узлы, не торговля вниманием. *Реализация: клиентский слой (app spec) + экономическая конструкция протокола (лотерея, TimeCoin).*
|
||
|
||
**4. Контроль данных.** Пользователь решает какие данные о нём существуют и кто имеет доступ. Не «политика конфиденциальности на 40 страниц», а технические механизмы: локальное шифрование на узле, выборочное предоставление доступа через адресное шифрование (ML-KEM), optional публикация профиля и контактов. Балансы публичны по дизайну ([I-2]). Всё остальное — решение владельца. *Реализация: протокол (I-2, модель приватности, Anchor = хэш без содержания) + клиентский слой (шифрование, selective sharing).*
|
||
|
||
### Архитектурное условие
|
||
|
||
Персональный интернет = протокол + свой узел + клиентский слой. Без любого из трёх — не работает.
|
||
|
||
- **Без протокола** — нет канонического времени, нет identity, нет Anchor, нет стимула. Клиентский слой не на чем строить.
|
||
- **Без своего узла** — данные на чужом узле. Это чужой iCloud в другой форме. Кошелёк и мессенджер работают, но обещание «мои данные под моим контролем» не выполняется.
|
||
- **Без клиентского слоя** — протокол производит примитивы, но человек не может ими воспользоваться. Нет приложения — нет продукта.
|
||
|
||
Montana делает личную инфраструктуру посильной: commodity hardware (минимум 1 ядро), окупаемость через лотерею (TimeCoin), открытое ПО. Но решение поставить узел — за человеком.
|
||
|
||
### Три примитива протокола
|
||
|
||
Протокол производит три примитива:
|
||
|
||
- **Каноническое время** — window_index, детерминированная последовательность событий через VDF
|
||
- **Передача ценности** — Transfer между аккаунтами, балансы в Account Table
|
||
- **Фиксация данных** — Anchor, 32 байта data_hash с привязкой к window_index, навсегда
|
||
|
||
Всё за пределами этих трёх примитивов — хранение данных, коммуникация, агенты, индексация, интерфейсы — реализуется клиентским слоем поверх протокола. Протокол — часы, бухгалтерия и нотариат. Серверов нет — каждый узел сети равноправен, принадлежит своему оператору и работает на своём оборудовании.
|
||
|
||
Консенсус: **Proof of Time (PoT)** — TimeChain: глобальная каноническая цепь (D последовательных SHA-256 = одно окно). NodeChain: последовательность cemented BundledConfirmation узла (доказательство присутствия). AccountChain: счётчик окон активности аккаунта. AccountTable: состояние счёта. Влияние узла = длина его NodeChain (chain_length = число окон с cemented BundledConfirmation). Протокол **и есть** структура отношений между событиями, оцифрованная и криптографически верифицируемая. Один узел = одно ядро CPU.
|
||
|
||
Genesis: symbolic window 0. Перевод window_index в любые внешние time scales является задачей клиентского слоя.
|
||
|
||
Генезис-фраза: `«Кто контролирует прошлое, контролирует будущее. Кто контролирует настоящее, контролирует прошлое.» — Оруэлл, 1984`
|
||
|
||
Эволюция протокола: открытые предложения (MIPs — Montana Improvement Proposals) публикуются как рекомендации, реализации выпускают новые версии, операторы узлов выбирают какую версию запускать. Fork resolution детерминирован через chain_length большинство. On-chain governance отсутствует. См. раздел «Эволюция протокола».
|
||
|
||
---
|
||
|
||
## Три решённые проблемы
|
||
|
||
### 1. Каноническая временная координата
|
||
|
||
**Проблема.** Существующие системы измерения времени (NTP, GPS, PTP) измеряют физическое время через доверенную инфраструктуру. Компрометация сервера NTP или отключение спутника GPS нарушает временную шкалу для всех зависимых систем. Использование таких систем в консенсусе протокола создаёт subjective input в consensus state.
|
||
|
||
**Решение.** Реляционная временная структура — сеть независимых VDF-осцилляторов, производящая каноническую последовательность событий через собственную работу. Каждый узел вычисляет цепочку событий автономно через последовательное SHA-256 хэширование. Результат детерминирован и верифицируем любым участником из canonical inputs.
|
||
|
||
**Свойства.** Montana Time обладает четырьмя свойствами:
|
||
|
||
- **Монотонность.** window_index строго возрастает. VDF последователен — каждый хэш зависит от предыдущего. Канонический порядок событий однозначен.
|
||
- **Детерминизм.** Все честные узлы согласны bit-exact на структуру событий — window_index, T_r, state_root. Каждое поле consensus state объективно вычислимо всеми узлами.
|
||
- **Верифицируемость.** Любой может пересчитать VDF и проверить каждое событие последовательности.
|
||
- **Независимость.** Каждый узел считает самостоятельно, опираясь только на canonical inputs протокола.
|
||
|
||
Montana и NTP/GPS/PTP — системы разных типов. NTP и GPS измеряют физическое время через внешние источники. Montana производит каноническую последовательность событий через собственную работу VDF и consensus.
|
||
|
||
### 2. Неплутократический консенсус
|
||
|
||
**Проблема.** В существующих консенсусных механизмах влияние пропорционально вычислительному бюджету или капиталу. Безопасность сети является функцией концентрации ресурсов, приобретаемых на рынке.
|
||
|
||
**Решение.** Proof of Time — механизм консенсуса, в котором влияние узла определяется исключительно длительностью его непрерывного присутствия в сети, измеренной в подписанных временных окнах. Вес узла = длина его NodeChain (количество окон, в которых узел криптографически доказал своё присутствие).
|
||
|
||
**Свойства.**
|
||
|
||
- Время — единственный ресурс, который нельзя приобрести, передать, делегировать или сконцентрировать
|
||
- Два участника, запустившие узлы одновременно, имеют равный вес независимо от капитала
|
||
- Стоимость атаки на консенсус выражается не в валюте, а во времени, и растёт линейно с возрастом сети
|
||
|
||
### 3. Window-based эмиссия
|
||
|
||
**Проблема.** Денежная политика фиатных валют определяется решениями комитетов и непредсказуема. Дефляционные модели с фиксированным потолком supply создают ожидание роста цены и подавляют использование как средства обмена.
|
||
|
||
**Решение.** Window-based эмиссия — денежная политика, в которой количество новых единиц за одно каноническое окно фиксировано и неизменно на всём горизонте существования протокола. Одно окно Montana Time порождает 13 единиц TimeCoin.
|
||
|
||
**Свойства.**
|
||
|
||
- Supply после окна W = `13 × (W + 1)` Ɉ
|
||
- Эмиссия линейна по window_index — инфляция монотонно убывает и асимптотически стремится к нулю
|
||
- Эмиссия не контролируется ни одним участником, комитетом или голосованием
|
||
- Денежная политика полностью определена единственной константой (13 Ɉ за окно) и не может быть изменена после генезиса
|
||
- Физическая скорость выпуска в SI-секундах определяется скоростью hardware сети и остаётся свойством клиентского слоя, вне scope консенсуса
|
||
|
||
### Следствие: цифровой reference frame времени без человека-посредника
|
||
|
||
Три решённые проблемы порождают уникальную возможность. Любой документ, событие, состояние может быть записано в Montana с математически доказуемой привязкой к канонической позиции в последовательности событий (window_index). Anchor — 32 байта, навсегда. Montana — не блокчейн с функцией timestamping. Montana — reference frame времени с функцией передачи ценности. Внешние системы могут наблюдать последовательность окон Montana и строить собственные переводы в свои локальные стандарты — этот перевод является задачей наблюдателя, не протокола.
|
||
|
||
Ни один человек, группа разработчиков, корпорация или совет не контролирует протокол. Изменения существуют только как открытые предложения и реализации, которые операторы узлов выбирают запускать.
|
||
|
||
---
|
||
|
||
## Глобальные инварианты протокола
|
||
|
||
Глобальный инвариант — свойство, которое протокол обязан сохранять во всех своих компонентах. Нарушение в одной части = нарушение во всём протоколе. Глобальные инварианты не имеют исключений и не подлежат локальному trade-off.
|
||
|
||
**[I-1] Постквантовая безопасность.** Все криптографические примитивы устойчивы к квантовому компьютеру. Допустимо: SHA-256 (Grover ослабляет до 128-bit, приемлемо), FN-DSA-512 (Falcon, lattice), ML-KEM (Kyber), ML-DSA (Dilithium), STARK (hash-based ZK), lattice commitments. Запрещено: ECDLP, RSA, классический Diffie-Hellman, Pedersen commitments на эллиптических кривых, Bulletproofs, Schnorr/EdDSA.
|
||
|
||
**[I-2] Открытость финансового слоя.** Балансы, суммы переводов, отправители, получатели — публичны. Никакого криптографического сокрытия на уровне протокола. См. «Модель приватности».
|
||
|
||
**[I-3] Детерминизм consensus state.** Любое состояние, входящее в consensus root, объективно вычислимо одинаково всеми узлами.
|
||
|
||
**Corollary I-3.a.** Любой механизм, результат которого в consensus state или в protocol-level behavior (mempool prioritization, gossip ordering, fork-choice, peer scoring) зависит от измерения физического мира — астрономического, геофизического, атомного, биологического или любого другого — отклоняется по нарушению I-3. Corollary применяется независимо от точности модели измерения.
|
||
|
||
**[I-4] Независимость TimeChain от Account state.** TimeChain продвигается из canonical inputs без зависимости от состояния Account Table. Зависимости однонаправленные: TimeChain → NodeChain (presence tracking) → AccountChain → AccountTable.
|
||
|
||
**[I-5] Реализуемость без специализированного оборудования.** Все примитивы имеют production-ready open-source реализации, работающие на commodity CPU узла без TEE, без обязательного GPU, без обязательного ASIC.
|
||
|
||
**[I-6] Регуляторная совместимость.** Протокол опирается на механизмы, совместимые с FATF/AML/MiCA/ETF. Запрещено: privacy mixers на уровне протокола, anonymous addresses, hidden flows, ring signatures, stealth addresses.
|
||
|
||
**[I-7] Минимальная криптографическая поверхность.** Каждый новый примитив требует обоснования закрытием конкретного механизма. Дублирование функциональности через два разных примитива запрещено.
|
||
|
||
### Модель приватности
|
||
|
||
Протокол разделяет публичное и приватное одним принципом: **consensus state — публичен, данные пользователя — за пределами протокола**.
|
||
|
||
- **Публично (consensus state):** балансы, суммы переводов, отправители, получатели, window_index, node_id, chain_length. Это следствие [I-2]: финансовый слой открыт для верификации.
|
||
- **В протоколе, но без содержания:** Anchor содержит data_hash (32 байта). Что за этим хэшем — протоколу неизвестно.
|
||
- **За пределами протокола:** данные пользователя (фото, сообщения, файлы) хранятся на узле владельца. Шифрование, формат хранения, доступ — решения клиентского слоя. Сеть не хранит, не реплицирует и не видит эти данные. Ключ шифрования — у владельца. Без ключа данные на узле — шум.
|
||
|
||
Протокол не предоставляет privacy через криптографическое сокрытие (нет ring signatures, нет hidden amounts, нет stealth addresses — [I-6]). Приватность данных обеспечивается архитектурно: данные не попадают в протокол. Протокол видит 32 байта хэша и всё.
|
||
|
||
### Language firewall
|
||
|
||
В нормативном тексте спецификации Montana допустимые термины для описания протокольных объектов, счётчиков, периодов или интервалов: `window`, `tick`, `epoch`, `cycle` — определённые через window counts. Термины физического времени (`second`, `minute`, `hour`, `day`, `week`, `month`, `year`) применяются только в advisory контекстах клиентского слоя и в описании транспортного уровня (implementation guidance).
|
||
|
||
---
|
||
|
||
## Montana Time
|
||
|
||
VDF — цифровой осциллятор в собственных единицах. `D` последовательных SHA-256 = одно окно τ₁ Montana. Число D представляет канонический объём работы, конституирующий единицу Montana Time.
|
||
|
||
TimeChain — глобальная каноническая цепь, поддерживаемая сетью узлов. Каждый узел вычисляет её независимо через последовательное хэширование. Результат детерминирован bit-exact — одни входные данные дают одну каноническую последовательность.
|
||
|
||
Токен — каноническая регистрация одного окна Montana Time. Протокол производит канонические окна и регистрирует каждое из них как 13 Ɉ.
|
||
|
||
### Определение Montana Time
|
||
|
||
```
|
||
montana_time(W) := W
|
||
```
|
||
|
||
Единственное каноническое определение времени в протоколе. Всё остальное — производные или advisory вычисления клиентского слоя.
|
||
|
||
Одно окно = `D` последовательных SHA-256 итераций от предыдущего canonical anchor. D фиксируется в Genesis Decree и может адаптироваться runtime-ом через participation-ratio feedback (см. раздел «Адаптация D»).
|
||
|
||
### Четыре свойства
|
||
|
||
- **Монотонность.** `window_index` строго возрастает. VDF последователен — каждый хэш зависит от предыдущего.
|
||
- **Детерминизм.** Все честные узлы согласны bit-exact на window_index, T_r, state_root. Каждое поле consensus state объективно вычислимо всеми узлами.
|
||
- **Верифицируемость.** Любой может пересчитать VDF и проверить каждое событие последовательности.
|
||
- **Независимость.** Каждый узел вычисляет канон сам, опираясь только на canonical inputs протокола.
|
||
|
||
Montana и NTP/GPS/PTP — системы разных типов. NTP и GPS измеряют физическое время через внешние источники. Montana производит каноническую последовательность событий через собственную работу VDF и consensus.
|
||
|
||
### Гранулярность
|
||
|
||
Атом Montana Time — одна SHA-256 итерация. Окно Montana Time — `D` атомов. Произвольный интервал — `N` окон. Все три уровня выражены в канонических числах, на которые bit-exact согласны все узлы.
|
||
|
||
Физическая длительность одной итерации зависит от hardware узла (наносекунды — десятки наносекунд на commodity CPU). Физическая длительность окна зависит от скорости железа узла и от участия сети. Физическая длительность — свойство конкретного наблюдателя, выводимое на клиентском слое.
|
||
|
||
### Time Oracle
|
||
|
||
Canonical `window_index` каждого proposal — верифицируемая координата события. Внешние системы используют Montana Time как reference frame:
|
||
|
||
- **Timestamping.** H(document) привязанный к window_index = криптографическое доказательство существования в позиции W канонической последовательности.
|
||
- **Ordering.** Два события, привязанные к разным window_index, имеют доказуемый канонический порядок.
|
||
- **Anchoring.** Внешний протокол якорится в Montana Time для независимой верификации порядка событий.
|
||
|
||
Перевод `window_index → физическое время` в любых внешних стандартах (UTC, TAI, GPS Time) является задачей клиентского слоя. Montana производит каноническую последовательность окон; внешний наблюдатель выбирает собственный метод привязки window_index к своим локальным временным единицам.
|
||
|
||
TimeChain хранится навсегда. Канонические координаты верифицируемы любым узлом в любой момент.
|
||
|
||
---
|
||
|
||
## Криптография
|
||
|
||
Два примитива с разделёнными ролями:
|
||
|
||
- **SHA-256** — консенсус (TimeChain), lottery endpoints, адреса, 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:
|
||
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. Финансовая приватность — задача приложений (микшеры, 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 (quorum event), а в конце окна при батчевом 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 == +13 Ɉ`:
|
||
|
||
```
|
||
apply_proposal step 2 (TimeCoin emission):
|
||
если winner_class = Node: operator_account.balance += 13_000_000_000 nɈ
|
||
если winner_class = Account: winner_account.balance += 13_000_000_000 nɈ
|
||
|
||
delta_supply за proposal = +13_000_000_000 nɈ ровно один раз
|
||
```
|
||
|
||
O(1) проверка на каждое state transition. Глобальный инвариант `Σ balance == 13 Ɉ × (window_index + 1)` истинен по индукции от genesis при условии что каждый переход поддерживает per-operation invariant.
|
||
|
||
```
|
||
genesis state (аксиома): window_index не определён, supply = 0, Σ balance = 0
|
||
первое окно: window_index = 0, supply = 13 Ɉ, Σ balance = 13 Ɉ
|
||
окно k: window_index = k, supply = 13 × (k+1) Ɉ, Σ balance = 13 × (k+1) Ɉ
|
||
```
|
||
|
||
Никаких откатов cemented операций не требуется — каждое cemented локально валидно по конструкции.
|
||
|
||
**τ₂ sanity check.** Дополнительная проверка раз в τ₂: пересчёт `Σ balance` по всей Account Table и сравнение с `13 Ɉ × (window_index + 1)`. Не load-bearing для финализации — служит для обнаружения багов реализации. Расхождение = немедленная остановка узла, дамп state для расследования.
|
||
|
||
### Перевод
|
||
|
||
Перевод на несуществующий account_id — отклоняется. Получатель обязан существовать в Account Table до получения перевода.
|
||
|
||
### TimeCoin
|
||
|
||
Победитель τ₁ регистрирует одно окно Montana Time: 13 Ɉ. При финализации proposal окна:
|
||
|
||
```
|
||
если winner_class = Node: operator_account.balance += 13_000_000_000 nɈ
|
||
если winner_class = Account: winner_account.balance += 13_000_000_000 nɈ
|
||
```
|
||
|
||
Атомарное обновление баланса. Узел получает награду через привязанный operator_account (зафиксирован при NodeRegistration). Никаких отдельных coinbase-структур, никаких отдельных таблиц эмиссии. Зачисление есть состояние Account Table.
|
||
|
||
```
|
||
Публичное (верифицируемо всеми):
|
||
TimeCoin: 13 Ɉ за окно (константа)
|
||
Supply audit: supply(window_index) = 13_000_000_000 × (window_index + 1) nɈ
|
||
Winner: winner_id в proposal header
|
||
Все балансы: Account Table
|
||
Все переводы: цепочки операций аккаунтов
|
||
VDF: TimeChain values, lottery endpoints, подписи
|
||
```
|
||
|
||
Псевдонимность на уровне account_id. Финансовая приватность — задача приложений: микшеры, 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. Если через 13 окон ни одна не набрала 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 операция за τ₁ (одно окно). Один Anchor содержит Merkle root от произвольного количества записей — throughput данных ограничен только размером Anchor. Для высокочастотных переводов — payment channels или application-level batching.
|
||
|
||
Спамер с 1000 новых аккаунтов: 1000 операций за τ₁ в бакете 0. Бакет 0 получает 1/4 от round-robin. Изолирован. Аккаунты в бакетах 1-3 не замечают.
|
||
|
||
---
|
||
|
||
## Состояние сети
|
||
|
||
Глобальное состояние = Account Table + Node Table + Candidate Pool.
|
||
|
||
```
|
||
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, окно регистрации (первое окно присутствия в Node Table)
|
||
chain_length 8B <- u64, позиция узла в NodeChain: = 1 при активации, +1 при cemented BundledConfirmation в окне. Инвариант: chain_length ≥ 1 для любого узла в Node Table
|
||
chain_length_snapshot 8B <- u64, = chain_length - chain_length_checkpoint[oldest]; используется в лотерее
|
||
chain_length_checkpoints 48B <- 6 × u64, checkpoint-ы chain_length на последних 6 τ₂-boundaries
|
||
last_confirmation_window 8B <- u64, window_index последнего окна с cemented BundledConfirmation
|
||
|
||
Candidate Pool (запись на кандидата):
|
||
node_id 32B <- SHA-256("mt-node" || node_pubkey)
|
||
node_pubkey 897B
|
||
suite_id 2B
|
||
operator_account_id 32B <- account_id куда зачисляется TimeCoin при победе
|
||
proof_endpoint 32B <- endpoint после 13 000 окон VDF
|
||
W_start 8B <- u64, окно начала VDF (заявлено кандидатом)
|
||
registration_window 8B <- u64, окно cementing NodeRegistration
|
||
expires 8B <- u64, registration_window + 3 × τ₂_windows
|
||
|
||
```
|
||
|
||
**Active node predicate (derived).** Узел считается активным если опубликовал cemented BundledConfirmation за последние 2τ₂:
|
||
|
||
```
|
||
active(node, W) = (W - node.last_confirmation_window) <= 2 × τ₂_windows
|
||
```
|
||
|
||
Predicate вычисляется из `last_confirmation_window` и текущего `window_index`. Применяется в quorum, confirmation_threshold, лотерее, валидации selection event.
|
||
|
||
### State Root
|
||
|
||
Merkle-дерево глобального состояния. Три подкорня обновляются при применении операций (apply_proposal и apply at window close):
|
||
|
||
```
|
||
state_root = SHA-256("mt-state-root" || node_root || candidate_root || account_root)
|
||
|
||
node_root: Merkle root Node Table, обновляется при selection event (регистрация),
|
||
chain_length increment (apply step 3.5), pruning узлов на τ₂.
|
||
candidate_root: Merkle root Candidate Pool, обновляется при cementing NodeRegistration
|
||
(добавление), selection event (удаление выбранных), expiry (удаление просроченных).
|
||
account_root: Merkle root Account Table, обновляется батчем при apply at window
|
||
close (все cemented операции окна применяются к state, затем
|
||
account_root пересчитывается).
|
||
|
||
Все три root соответствуют settled state (после apply at window close).
|
||
Порядок node_root → candidate_root → account_root отражает направление
|
||
зависимостей: узлы — активные участники, кандидаты — будущие узлы, аккаунты — финансовый слой.
|
||
Domain separator `mt-state-root` отличён от `mt-merkle-node` — 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 хэшей.
|
||
|
||
**Структура Candidate Pool Root:** sparse Merkle tree глубины 256, индексированный по `node_id`. Empty root = `0x00 × 32`.
|
||
|
||
Каждый узел в Node Table — участник сети. Узел существует в таблице = участвует.
|
||
|
||
Все sort keys фиксированной длины. Побайтовое лексикографическое сравнение. Две реализации с одинаковыми данными строят одинаковое дерево и получают одинаковый State Root.
|
||
|
||
State Root коммитится в заголовке каждого proposal τ₁. `account_root`, `node_root` и `candidate_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τ₂ (52 000 окон)
|
||
AND is_node_operator == 0 <- не привязан как operator узла
|
||
AND нет cemented NodeRegistration в control_set <- нет pending привязки
|
||
ожидающего apply, ссылающегося на этот account_id
|
||
```
|
||
|
||
Пустой аккаунт без активности 4τ₂ — удаляется, кроме:
|
||
- 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 — глобальные часы (ход времени, VDF). NodeChain — присутствие узла (последовательность cemented BundledConfirmation). 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 в каждом окне. Каждое окно с cemented BundledConfirmation = одно звено NodeChain. chain_length — позиция узла в NodeChain: = 1 при активации (Genesis для bootstrap, selection event для нового узла), +1 при каждом cemented BundledConfirmation. Инвариант: chain_length ≥ 1 для любого узла в Node Table — гарантирует корректность знаменателей в weighted_ticket лотереи и в seniority_bonus.
|
||
|
||
NodeChain не является VDF-цепочкой. Узел доказывает присутствие публикацией BundledConfirmation (подтверждение операций сети), не вычислением per-node VDF. Один VDF на всю сеть (TimeChain) — достаточен.
|
||
|
||
NodeChain зависит от TimeChain (якорится через window_index). TimeChain не зависит от NodeChain.
|
||
|
||
**Liveness узла и сетевое включение.** Рост chain_length требует cementing BundledConfirmation через confirmation threshold 67% active_chain_length. При стандартной BFT-assumption (≥67% active_chain_length честны и достижимы по P2P) BC активного узла cemented в каждом окне участия. Изоляция узла от confirmers (eclipse, network partition, propagation failure) останавливает рост chain_length независимо от локальной работы узла. Это свойство consensus-механизма, не свойство узла: chain_length измеряет подтверждённое сетью присутствие, не локальную CPU-работу.
|
||
|
||
### 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 и AccountChain:**
|
||
|
||
| Свойство | NodeChain | AccountChain |
|
||
|----------|-----------|--------------|
|
||
| Источник | node_pubkey | account_pubkey |
|
||
| Идентификатор | node_id | account_id |
|
||
| Тип присутствия | машинное | человеческое |
|
||
| Ритм | непрерывный (каждое окно) | дискретный (окно с операцией) |
|
||
| Длина | chain_length (окна с BundledConfirmation) | account_chain_length (окна с операцией) |
|
||
| Единица длины | окно τ₁ | окно τ₁ |
|
||
| Накопление | автоматически при публикации BundledConfirmation | через активность пользователя |
|
||
| Защита от подделки | подпись FN-DSA-512 | подпись FN-DSA-512 |
|
||
| Защита от Sybil | 13 000 окон + selection event | накопление окон требует активности |
|
||
|
||
Узел доказывает присутствие публикацией BundledConfirmation в каждом окне. Аккаунт — операцией. Оба механизма верифицируемы, оба производят запись на одной шкале времени.
|
||
|
||
AccountChain зависит от TimeChain напрямую. AccountChain не зависит от NodeChain по построению.
|
||
|
||
### VDF Reveal и лотерея
|
||
|
||
В лотерее участвуют два класса субъектов: **узлы** (через VDF_Reveal) и **аккаунты** (через cemented операции). Каждый класс производит ticket, взвешенный по длине своей цепочки.
|
||
|
||
Confirmers (~100 узлов с наибольшим chain_length) публикуют BundledConfirmation для финализации окна. Все узлы с weighted_ticket < target публикуют VDF_Reveal для лотереи. VDF_Reveal цементируется через BundledConfirmation: confirmers включают полученные VDF_Reveals в свои bundles наряду с UserObjects и ControlObjects. Cement threshold тот же — 67% active_chain_length. Proposer извлекает только cemented reveals — дискреция над лотереей = ноль.
|
||
|
||
#### Класс 1: узлы
|
||
|
||
После завершения VDF окна W каждый узел вычисляет свой ticket:
|
||
|
||
```
|
||
ticket_node = -ln(endpoint_node / 2^256)
|
||
|
||
seniority_bonus = min(chain_length / 69, chain_length_snapshot)
|
||
lottery_weight = chain_length_snapshot + seniority_bonus
|
||
|
||
weighted_ticket_node = ticket_node / lottery_weight
|
||
```
|
||
|
||
`chain_length_snapshot` — количество окон с cemented BundledConfirmation за последние 6τ₂ (78 000 окон). Вычисляется через checkpoint-механизм: на каждой τ₂-boundary фиксируется checkpoint chain_length; snapshot = chain_length - checkpoint_6τ₂_ago. Хранится 6 checkpoint-ов (48B на узел). Обновляется на τ₂-boundary (шаг 3.6 apply_proposal).
|
||
|
||
`seniority_bonus` — добавка за накопленный абсолютный chain_length, ограниченная сверху размером snapshot (cap). Делитель 69 (цифровой корень = 6, Tesla). Cap = snapshot: максимальное преимущество старожила ≈ 2x относительно новичка с полным snapshot. При chain_length < 69 seniority_bonus = 0 (целочисленное деление): первые 69 окон после регистрации lottery_weight = snapshot.
|
||
|
||
Разделение весов:
|
||
- **Лотерея (эмиссия):** `lottery_weight = chain_length_snapshot + seniority_bonus`. Недавняя работа (snapshot) доминирует, longevity даёт bounded bonus.
|
||
- **Quorum (безопасность):** абсолютный `chain_length`. Старожилы доминируют в финализации.
|
||
|
||
Endpoint узла вычисляется детерминированно из канонических данных:
|
||
|
||
```
|
||
endpoint_node(W) = SHA-256("mt-lottery" || T_r(W) || node_id || window_index)
|
||
```
|
||
|
||
Где T_r(W) — TimeChain VDF output окна W (каноничен, одинаков у всех узлов). Endpoint верифицируем за O(1) — один SHA-256.
|
||
|
||
Если weighted_ticket_node < target — узел кандидат и публикует VDF_Reveal:
|
||
|
||
```
|
||
VDF_Reveal:
|
||
node_id 32B
|
||
window_index 4B <- индекс τ₁
|
||
endpoint 32B <- SHA-256("mt-lottery" || T_r || node_id || window_index)
|
||
signature 666B <- FN-DSA-512, подписано node_pubkey
|
||
Итого: ~734B
|
||
```
|
||
|
||
Любой активный узел может стать кандидатом лотереи — lottery_weight основан на недавней работе (snapshot 6τ₂), старожилы получают bounded seniority bonus.
|
||
|
||
#### Класс 2: аккаунты
|
||
|
||
Аккаунт автоматически становится кандидатом если у него есть cemented операция в окне W. 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 — все узлы используют одно значение, лотерея детерминирована.
|
||
|
||
Аккаунт без операции в окне W не участвует в лотерее этого окна.
|
||
|
||
**Исключение operator-аккаунтов.** Аккаунт с `is_node_operator = 1` исключён из лотереи аккаунтов. Узел получает вес через NodeChain; operator_account только хранит TimeCoin. Двойной счёт исключён конструкцией. Оператор узла, желающий участвовать в лотерее аккаунтов, использует отдельный персональный аккаунт.
|
||
|
||
**Защита от grinding:** dependency rule ограничивает аккаунт одной операцией за окно — один лотерейный билет. timechain_value(W) известен только после закрытия окна — endpoint непредсказуем заранее.
|
||
|
||
#### Определение winner-а (Lookback Leadership)
|
||
|
||
Winner окна W-1 определяется при cementing proposal окна W. Proposer окна W = winner окна W-2 (канонически известен из cemented state).
|
||
|
||
**Механика:**
|
||
|
||
1. Окно W-1 завершается: confirmers публикуют BundledConfirmation_{W-1} (операции окна W-1 + VDF_Reveals окна W-2), кандидаты публикуют VDF_Reveal_{W-1}, аккаунты публикуют операции.
|
||
2. `proposer_W = winner_{W-2}` (канонически определён из proposal_{W-1}).
|
||
3. Окно W начинается. Confirmers получают VDF_Reveals_{W-1} через P2P и включают их в BundledConfirmation_W наряду с операциями окна W. VDF_Reveal идентифицируется по `window_index = W-1`.
|
||
4. VDF_Reveal_{W-1} cemented когда confirmers с суммарным chain_length ≥ 67% active_chain_length включили его в свои BundledConfirmation_W. Cement status каноничен — каждый узел отслеживает его независимо по P2P bundles.
|
||
5. Proposer_W собирает BundledConfirmation-ы окна W-1 и cemented set:
|
||
```
|
||
included_bundles_{W-1} = BundledConfirmation-ы окна W-1 из view proposer-а
|
||
(суммарный chain_length ≥ 67% active_chain_length)
|
||
included_reveals_{W-1} = VDF_Reveal-ы окна W-1, cemented через
|
||
BundledConfirmation окна W (67% active_chain_length)
|
||
```
|
||
6. Из included_reveals_{W-1} извлекаются все node endpoints. Из included_bundles_{W-1} извлекаются все cemented account operations.
|
||
7. `winner_{W-1} = argmin(weighted_ticket)` среди всех кандидатов (cemented VDF_Reveal nodes + аккаунты).
|
||
8. Proposer_W публикует proposal_W, содержащий:
|
||
- `included_bundles_{W-1}` (canonical view финализации)
|
||
- `included_reveals_{W-1}` (cemented set лотереи)
|
||
- `winner_{W-1}` (получатель 13 Ɉ за окно W-1)
|
||
- control_set, state_root, TimeCoin transfer
|
||
9. Сеть валидирует proposal_W:
|
||
- Proposer = winner_{W-2}? (канонически проверяемо)
|
||
- included_bundles содержат ≥ 67% active_chain_length? (проверяемо из Node Table)
|
||
- included_reveals_{W-1} = cemented set VDF_Reveals окна W-1? (валидатор сверяет с собственным tracking cement status из BundledConfirmation окна W)
|
||
- winner_{W-1} = argmin из (included_reveals ∪ account_candidates)? (детерминированно проверяемо)
|
||
- state_root корректен? (независимый пересчёт)
|
||
10. Если 67% active_chain_length подписывают proposal_W → proposal cemented. Winner_{W-1} получает 13 Ɉ. Winner_{W-1} становится proposer_{W+1}.
|
||
11. Если < 67% подписали → proposal отклонён. Fallback: `fallback_proposer_W = second_min(weighted_ticket)` окна W-2. Fallback cascade: third_min, fourth_min, etc.
|
||
|
||
**Cross-window cementing timeline.** VDF_Reveals окна W-1 публикуются при завершении окна W-1 (VDF computation = window duration). Цементируются в BundledConfirmation окна W. Между публикацией reveals и сборкой proposal — целое окно. Timing constraint отсутствует.
|
||
|
||
**Leader skin in the game.** Proposer_W публикует свой VDF_Reveal для окна W. Если его proposal отклонён (< 67% подписей сети), его VDF_Reveal исключается из пула кандидатов окна W. Потеря lottery ticket = экономический кнут за цензуру или бездействие. Отказ подписать proposal = implicit rejection от каждого узла.
|
||
|
||
**Genesis bootstrap.** proposer_0 и proposer_1 = bootstrap-узел (единственный в Genesis Decree). Начиная с proposer_2 = winner_0, стандартная lookback логика.
|
||
|
||
#### Калибровка target
|
||
|
||
Target калиброван на ~13 кандидатов VDF_Reveal за окно. Калибровка на τ₂:
|
||
|
||
```
|
||
target_new = target_old × (13 / actual_candidates_per_window)
|
||
actual_candidates_per_window = total_reveals_за_τ₂ / 13 000
|
||
```
|
||
|
||
Трафик reveal за окно: ~13 VDF_Reveal × 738B ≈ 9.6 KB (P2P gossip; далее включаются в BundledConfirmation для cementing). Аккаунты участвуют через cemented операции в BundledConfirmation — дополнительного трафика для аккаунтов нет.
|
||
|
||
#### Валидация VDF_Reveal
|
||
|
||
1. Подпись FN-DSA-512 соответствует node_pubkey из Node Table
|
||
2. window_index = текущий τ₁
|
||
3. node_id существует в Node Table
|
||
4. weighted_ticket < target
|
||
5. endpoint верифицируем: SHA-256("mt-lottery" || T_r || node_id || window_index) = заявленному endpoint
|
||
|
||
#### Валидация участия аккаунта
|
||
|
||
1. account_id существует в Account Table
|
||
2. account_chain_length_snapshot > 0
|
||
3. Аккаунт имеет cemented операцию в окне W
|
||
4. operation_for_lottery определена детерминированно (dependency rule: одна операция за окно)
|
||
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** — объекты управляющие составом сети:
|
||
|
||
| Тип | Описание | Валидация |
|
||
|-----|----------|-----------|
|
||
| NodeRegistration | Регистрация узла (кандидатура) | FN-DSA-512 подпись, node_id уникален (не в Node Table и не в Candidate Pool), operator_account_id существует, proof_endpoint верифицируем через VDF от candidate_vdf_init |
|
||
|
||
Каждый узел валидирует объекты обоих классов локально при получении. Валидные объекты ретранслируются по P2P.
|
||
|
||
Все объекты — UserObjects, ControlObjects и VDF_Reveals — финализируются (cemented) одинаково: через 67% active_chain_length подтверждения в BundledConfirmation. Cemented status объективен и одинаков для всех узлов. Дискреция победителя над включением ControlObjects и VDF_Reveals = ноль.
|
||
|
||
#### 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 за одну операцию → побеждает (см. раздел «Двойная трата»).
|
||
|
||
#### Закрытие окна (Lookback Leadership Finalization)
|
||
|
||
```
|
||
Window W-1: confirmers publish BundledConfirmation_{W-1}
|
||
(W-1 operations + W-2 VDF_Reveals)
|
||
VDF_{W-1} completes → candidates publish VDF_Reveal_{W-1}
|
||
accounts publish cemented operations
|
||
│
|
||
Window W: confirmers publish BundledConfirmation_W
|
||
(W operations + W-1 VDF_Reveals)
|
||
W-1 VDF_Reveals cemented (67% active_chain_length)
|
||
│
|
||
proposer_W = winner_{W-2} (canonical from proposal_{W-1})
|
||
proposer_W extracts cemented reveals → winner_{W-1}
|
||
proposer_W publishes proposal_W
|
||
│
|
||
▼
|
||
┌───────────────────────────────┐
|
||
│ proposal_W validation │
|
||
│ included_bundles ≥ 67%? │
|
||
│ included_reveals = cemented? │
|
||
│ winner_{W-1} = argmin? │
|
||
│ state_root correct? │
|
||
└───────────┬───────────────────┘
|
||
│ 67% sign
|
||
▼
|
||
proposal_W cemented
|
||
winner_{W-1} receives 13 Ɉ
|
||
winner_{W-1} = proposer_{W+1}
|
||
```
|
||
|
||
- **Lookback Leader.** `proposer_W = winner_{W-2}` — канонически определён из cemented proposal_{W-1}. Каждый узел вычисляет proposer_W детерминированно из canonical state.
|
||
- **Cemented reveals.** VDF_Reveals окна W-1 публикуются при завершении W-1, цементируются чер<D0B5><D180>з BundledConfirmation окна W (confirmers включают полученные reveals в свои bundles). `included_reveals_{W-1}` = cemented set (67% active_chain_length). Proposer извлекает cemented reveals и cemented account operations из included_bundles_{W-1}, определяет `winner_{W-1} = argmin(weighted_ticket)`. Дискреция proposer-а над составом лотереи = ноль.
|
||
- **Canonical acceptance.** Сеть валидирует proposal_W: (a) proposer = winner_{W-2}, (b) included_bundles ≥ 67% active_chain_length, (c) included_reveals = cemented set VDF_Reveals окна W-1, (d) winner_{W-1} = argmin из (cemented reveals ∪ account_candidates), (e) state_root корректен. Если 67% active_chain_length подписывают proposal_W → cemented. Canonical set зафиксирован.
|
||
- **Leader skin in the game.** Proposer_W участвует в лотерее окна W через свой VDF_Reveal (cemented в BundledConfirmation окна W+1). При отклонении proposal (< 67% подписей) — VDF_Reveal proposer-а исключается из пула кандидатов окна W. Отказ подписать proposal = implicit rejection. Отдельного censorship vote нет.
|
||
- **Fallback cascade.** Если proposal от proposer_W отклонён или отсутствует, роль переходит к `fallback_1 = second_min(weighted_ticket)` окна W-2, затем third_min, etc. Все канонически известны из cemented state.
|
||
- **ControlObjects.** ControlObjects попадают в control_set proposal по моменту cement — canonically deterministic.
|
||
|
||
**Свойство темпа сети.** Сеть продвигается со скоростью медианного активного набора узлов. Quorum требует подписей большинства по chain_length — быстрейший узел ждёт, пока достаточно других успеет. Hardware progress ускоряет сеть естественно — когда ускоряется медиана, participation_ratio растёт выше 0.95, D адаптивно увеличивается.
|
||
|
||
**One-window lag награды.** 13 Ɉ за окно W-1 зачисляются winner_{W-1} при cementing proposal_W. Задержка в одно окно между завершением работы и получением награды.
|
||
|
||
#### Proposer (Lookback Leader)
|
||
|
||
`proposer_W = winner_{W-2}` — канонически определён из cemented proposal_{W-1}. Proposer собирает proposal_W:
|
||
|
||
- **included_bundles_{W-1}**: BundledConfirmation окна W-1 (суммарный chain_length ≥ 67% active_chain_length). Из included_bundles извлекаются cemented account operations для лотереи.
|
||
- **included_reveals_{W-1}**: VDF_Reveals окна W-1, cemented через BundledConfirmation окна W (67% active_chain_length). Из cemented reveals + cemented account operations определяется `winner_{W-1}` (получатель 13 Ɉ за окно W-1).
|
||
- **control_set**: все cemented ControlObjects в окнах (previous_proposal.window, W]. Свобода = ноль (каноничен).
|
||
- **State Root snapshot**: account_root, node_root и candidate_root после apply at window close (все cemented операции + control objects + selection event + TimeCoin transfer to winner_{W-1} применены батчем).
|
||
|
||
Свобода proposer: included_bundles ограничены порогом 67%. included_reveals детерминированы cement status-ом. control_set детерминирован формулой. State root и winner_{W-1} вычисляются из cemented sets — каждый валидатор проверяет корректность детерминированно.
|
||
|
||
Proposal с набором included_bundles < 67% active_chain_length, неверным included_reveals (не совпадает с cemented set), неверным winner_{W-1}, пропущенным cemented ControlObject, или неверным state_root отклоняется → fallback на second_min(weighted_ticket) окна W-2.
|
||
|
||
#### Финальность 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. Каждый узел независимо вычисляет ожидаемый control_set по формуле и сравнивает с proposer's
|
||
4. Каждый узел применяет control_set + TimeCoin детерминированно в порядке (cemented_window asc, op_hash lex asc)
|
||
5. Каждый узел сравнивает вычисленный state_root с заявленным в proposal
|
||
6. Совпадает — proposal принят
|
||
7. Не совпадает — 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 (обновляется каждое окно)
|
||
candidate_root 32B <- Merkle root Candidate Pool
|
||
account_root 32B <- Merkle root Account Table после apply at window close
|
||
state_root 32B <- SHA-256("mt-state-root" || node_root || candidate_root || account_root)
|
||
timechain_value 32B
|
||
included_bundles_root 32B <- Merkle root списка (confirmer_id, bundle_hash)
|
||
BundledConfirmation окна W-1 (≥ 67% active_chain_length)
|
||
included_reveals_root 32B <- Merkle root списка VDF_Reveal-ов окна W-1,
|
||
cemented через BundledConfirmation окна W
|
||
winner_class 1B <- 1=Node, 2=Account (winner окна W-1)
|
||
winner_endpoint 32B <- endpoint winner-а окна W-1 (node lottery или account lottery)
|
||
winner_id 32B <- получатель TimeCoin за окно W-1: node_id (winner_class=1)
|
||
или account_id (winner_class=2)
|
||
proposer_node_id 32B <- winner_{W-2}, канонически определённый из proposal_{W-1}
|
||
target 8B <- текущий target лотереи
|
||
fallback_depth 1B <- 1 = первое место, 2+ = fallback
|
||
signature 666B <- FN-DSA-512, подпись header Node Table[proposer_node_id].node_pubkey
|
||
```
|
||
|
||
Все поля proposal header канонически вычислимы bit-exact из предыдущего state и cemented set окна W. Каждое поле имеет источником либо canonical state, либо детерминированную функцию от canonical state.
|
||
|
||
**Разделение ролей winner_id и proposer_node_id.** Это два независимых поля с разными назначениями:
|
||
|
||
- `winner_id` — получатель TimeCoin. Аккаунт или узел, выигравший лотерею окна. Используется только в apply_proposal step 2 для зачисления 13 Ɉ.
|
||
- `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 которую его реализация не поддерживает; принятие неизвестной версии = принятие непроверяемых правил = нарушение безопасности)
|
||
|
||
**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_W = winner_{W-2}` отклонён (< 67% подписей) или отсутствует (proposer offline), роль переходит к `fallback_1 = second_min(weighted_ticket)` окна W-2. Если fallback_1 тоже отклонён — к third_min, и т.д. Вся cascade канонически определена из cemented state окна W-2.
|
||
|
||
При fallback `proposer_node_id` меняется; `winner_{W-1}` определяется fallback-proposer-ом из cemented set (тот же cemented set — canonical для всех узлов). Новый proposer подписывает header своим node_pubkey, `fallback_depth` инкрементируется.
|
||
|
||
**Leader penalty при отклонении:** endpoint proposer-а, чей proposal отклонён, исключается из lottery пула текущего окна W. Proposer теряет шанс на 13 Ɉ. Это экономический кнут за бездействие или цензуру.
|
||
|
||
**Полная симметрия fallback:** молчание первого proposer переводит обязанность сборки proposal к следующему узлу. Награда за окно W-1 привязана к лотерейному билету и гарантирована, если хотя бы один узел в сети соберёт валидный proposal через fallback cascade.
|
||
|
||
#### Непрерывность VDF
|
||
|
||
VDF следующего окна вычисляется непрерывно, не ожидая завершения финализации предыдущего. TimeChain для окна N+1 детерминирован — каждый узел вычисляет его независимо. 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) / 130
|
||
~130 confirmers при large-scale сети (active_chain_length / 130).
|
||
```
|
||
|
||
Только активные узлы (cemented BundledConfirmation за последние 2τ₂) учитываются. Мёртвый вес исключён конструкцией. Сканирование Node Table для вычисления `active_chain_length` — O(|Node Table|) ≤ 10⁵ записей, миллисекунды.
|
||
|
||
Confirmer собирает все валидные объекты за окно и публикует один BundledConfirmation. Bundle содержит два класса хэшей: (1) операции текущего окна W (UserObjects + ControlObjects) и (2) VDF_Reveals предыдущего окна W-1 (лотерейные билеты, опубликованные при завершении W-1 и полученные через P2P):
|
||
|
||
```
|
||
BundledConfirmation:
|
||
node_id 32B
|
||
endpoint 32B <- T_r текущего окна (доказывает timeliness)
|
||
window_index 4B
|
||
op_count 2B
|
||
op_hashes[] op_count × 32B <- хэши UserObjects и ControlObjects окна W
|
||
reveal_count 2B
|
||
reveal_hashes[] reveal_count × 32B <- хэши VDF_Reveals окна W-1
|
||
signature 666B
|
||
```
|
||
|
||
Один BundledConfirmation per (node_id, window_index). Повторный отклоняется. Endpoint = T_r текущего окна (верифицируем: сравнение с каноническим T_r). `node.chain_length` хранится в Node Table и инкрементируется в `apply_proposal` шаг 3.5 для каждого узла с cemented BundledConfirmation в окне W.
|
||
|
||
Объект финализирован (cemented) когда подтверждения от confirmers с суммарным chain_length > quorum. Cemented — необратимо. Типичное время: quorum event. Это правило применяется одинаково к UserObjects, ControlObjects и VDF_Reveals: cemented status объективен и каноничен для всех узлов. VDF_Reveals окна W-1 цементируются в BundledConfirmation окна W (cross-window cementing).
|
||
|
||
**Confirmation cutoff (детерминизм cemented set).** Cemented set окна W фиксируется proposer-ом окна W+1 через frozen view (Lookback Leadership). Proposer_{W+1} включает в proposal_{W+1} все BundledConfirmation окна W из своего view с суммарным chain_length ≥ 67% active_chain_length. Этот frozen view становится каноническим cemented set после cementing proposal_{W+1} сетью.
|
||
|
||
**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 операция за окно. Это достаточно для всех бытовых сценариев; для высокочастотных — 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 буферизуются до момента сборки proposal_{W+1}. Множество cemented операций фиксируется proposer-ом через frozen view (Lookback Leadership). Все 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).
|
||
NodeRegistration: проверить node_id уникален (нет в Node Table и Candidate Pool),
|
||
проверить operator_account_id существует и is_node_operator == 0,
|
||
проверить W_start >= W_p - 2 × τ₂_windows,
|
||
вычислить effective_vdf_length(W_start) из canonical state на окно W_start
|
||
(candidate_pressure = pending_candidates / active_nodes,
|
||
if > 0.01: 13000 × pressure × 100, else: 13000),
|
||
верифицировать proof_endpoint: пересчёт VDF от
|
||
SHA-256("mt-candidate-vdf-init" || timechain_value(W_start) || node_id)
|
||
через effective_vdf_length(W_start) окон,
|
||
создать запись в Candidate Pool:
|
||
node_id, node_pubkey, suite_id, operator_account_id,
|
||
proof_endpoint, W_start,
|
||
registration_window = W_p,
|
||
expires = W_p + 3 × τ₂_windows.
|
||
|
||
Шаг 2: применить TimeCoin победителя.
|
||
Если winner_class = 1 (Node): operator_account = Node Table[winner_id].operator_account_id
|
||
operator_account.balance += 13_000_000_000 nɈ
|
||
Если winner_class = 2 (Account): Account Table[winner_id].balance += 13_000_000_000 nɈ
|
||
Proposer (proposer_node_id) формирует proposal без награды.
|
||
|
||
Шаг 3: обработать expiry кандидатов и selection event.
|
||
3a. Все записи c ∈ Candidate Pool где c.expires <= current_window:
|
||
удалить c из Candidate Pool, обновить candidate_root.
|
||
3b. Selection event (если current_window % 369 == 0):
|
||
candidates = все записи Candidate Pool где expires > current_window
|
||
slots = max(1, floor(active_nodes(current_window) / 130))
|
||
sort_key(c) = SHA-256(timechain_value(current_window) || c.node_id)
|
||
selected = первые slots кандидатов по sort_key
|
||
Для каждого selected:
|
||
создать запись в Node Table (start_window = current_window, chain_length = 1,
|
||
last_confirmation_window = 0, operator_account_id зафиксирован)
|
||
установить is_node_operator = 1 у operator-аккаунта
|
||
удалить selected из Candidate Pool
|
||
обновить node_root и candidate_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 объективен) — все узлы применяют один и тот же набор обновлений.
|
||
|
||
Шаг 3.6: обновить chain_length_snapshot на τ₂-boundary.
|
||
Если current_window % τ₂_windows == 0:
|
||
Для каждого узла N в Node Table:
|
||
rotate N.chain_length_checkpoints (сдвиг: oldest выбывает, текущий chain_length записывается как newest)
|
||
N.chain_length_snapshot = N.chain_length - N.chain_length_checkpoints[oldest]
|
||
update_merkle_path(N) в node_root
|
||
Между τ₂-boundaries: chain_length_snapshot вычисляется как chain_length - frozen oldest checkpoint.
|
||
Детерминированно: все узлы применяют одну и ту же ротацию на одной τ₂-boundary.
|
||
|
||
Шаг 4: node_root, candidate_root и account_root уже отражают все cemented изменения
|
||
(incremental Merkle update произошёл при каждом state transition).
|
||
state_root = SHA-256("mt-state-root" || node_root || candidate_root || account_root).
|
||
```
|
||
|
||
Порядок детерминирован. Каждый узел применяет одни и те же шаги и получает один и тот же state_root.
|
||
|
||
AccountTable зависит от TimeChain, NodeChain и AccountChain. Обратных зависимостей нет.
|
||
|
||
Минимум для узла: **1 ядро CPU**. TimeChain VDF (непрерывное последовательное хэширование) + валидация операций (interleaved, overhead < 1% окна). С ростом TPS сети дополнительные ядра ускоряют верификацию операций. Один узел = 1 ядро. Любой компьютер = потенциальный узел. Верификация операций аккаунтов полностью параллелизуется — цепочки аккаунтов независимы.
|
||
|
||
### Вход и регистрация
|
||
|
||
Два уровня входа в сеть. Узлы участвуют в консенсусе — открытый вход через VDF + selection event. Аккаунты держат и переводят средства — создаются явно через OpenAccount.
|
||
|
||
**Genesis State — аксиома сети.** Минимальный bootstrap: один узел, один аккаунт. Начальное состояние, существующее до того как любая операция возможна:
|
||
|
||
```
|
||
Genesis State (до первого окна, supply = 0):
|
||
|
||
Account Table = 1 запись (bootstrap operator account):
|
||
account_id = SHA-256("mt-account" || suite_id || pubkey_0)
|
||
balance = 0
|
||
suite_id = 0x0001 (FN-DSA-512)
|
||
is_node_operator = 1
|
||
current_pubkey = pubkey_0 (bootstrap)
|
||
frontier_hash = SHA-256("mt-genesis" || account_id)
|
||
op_height = 0
|
||
account_chain_length = 0
|
||
account_chain_length_snapshot = 0
|
||
creation_window = 0
|
||
|
||
Node Table = 1 запись (bootstrap node):
|
||
node_id = SHA-256("mt-node" || node_pubkey_0)
|
||
node_pubkey = node_pubkey_0 (bootstrap)
|
||
suite_id = 0x0001
|
||
operator_account_id = account_id_0
|
||
start_window = 0
|
||
chain_length = 1
|
||
last_confirmation_window = 0
|
||
|
||
Candidate Pool = ∅
|
||
|
||
Bootstrap-узел стартует с chain_length = 1 в Genesis. Каждый последующий cemented BundledConfirmation инкрементирует chain_length. Начальное значение = 1 (а не 0) — необходимо для корректности знаменателей weighted_ticket_node и seniority_bonus; инвариант chain_length ≥ 1 сохраняется для любого узла в Node Table.
|
||
|
||
genesis_account_root = sparse Merkle root над 1 записью Account Table
|
||
genesis_node_root = sparse Merkle root над 1 записью Node Table
|
||
genesis_candidate_root = 0x00 × 32 (пустая sparse Merkle tree)
|
||
genesis_state_root = SHA-256("mt-state-root" || genesis_node_root || genesis_candidate_root || genesis_account_root)
|
||
|
||
protocol_params (каноническая сериализация, little-endian, фиксированная длина полей):
|
||
D₀ (8B) начальное значение D TimeChain VDF (13 000 000 000)
|
||
(reserved) (8B) = 0x00 × 8 (mandatory, ранее m₀ NodeChain VDF)
|
||
τ₂_windows (8B) число окон в τ₂ (13 000)
|
||
timecoin_per_window (16B) 13_000_000_000 nɈ (u128)
|
||
target₀ (32B) начальный target лотереи
|
||
confirmation_quorum_num (1B) 67
|
||
confirmation_quorum_den (1B) 100
|
||
participation_dead_zone_low (2B) 85
|
||
participation_dead_zone_high (2B) 95
|
||
d_adjustment_rate_num (2B) 3
|
||
d_adjustment_rate_den (2B) 100
|
||
vdf_entry_windows (8B) 13 000
|
||
selection_interval (8B) 369
|
||
candidate_expiry_windows (8B) 39 000 (3τ₂)
|
||
adaptive_vdf_threshold (2B) 1 (= 0.01 × 100, порог давления 1%)
|
||
adaptive_vdf_multiplier (2B) 100 (effective_vdf = base × pressure × multiplier)
|
||
pruning_idle_windows (8B) 52 000 (4τ₂)
|
||
bootstrap_account_pubkey (897B)
|
||
bootstrap_node_pubkey (897B)
|
||
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)
|
||
```
|
||
|
||
Bootstrap keypair (account + node) публикуется в Genesis Decree вместе с протокольными параметрами и Genesis State Hash. Genesis Decree immutable — закреплён в коде каждой реализации.
|
||
|
||
**Валидация Genesis Decree.** Каждая реализация при старте вычисляет Genesis State Hash из сериализованных protocol_params и сверяет с эталонным значением, закреплённым в коде. Любое отклонение — включая ненулевые байты в reserved поле — делает Genesis Decree недействительным, узел отказывается стартовать. Reserved поле = 0x00 × 8 строго; любое другое значение изменяет Genesis State Hash и создаёт несовместимую сеть.
|
||
|
||
Первое окно τ₁ после генезиса — window_index = 0, protocol_version = 1. Bootstrap-узел — единственный proposer первых двух окон (без lookback). Начиная с W = 2 — стандартная lookback логика. Bootstrap-узел получает 13 Ɉ за каждое выигранное окно. Per-operation invariant действует с первого окна.
|
||
|
||
**Bootstrap period.** До появления второго узла (первые 13 000+ окон) bootstrap-узел имеет 100% active_chain_length и является единственным confirmer-ом, proposer-ом и winner-ом. Это физическая необходимость запуска любой сети — кто-то является первым. Доминирование bootstrap-узла размывается органически: каждый новый узел, прошедший selection event, вносит свой chain_length в active set. Протокольные правила (quorum 67%, weighted_ticket лотерея, selection rate limit) одинаковы с первого окна — специальных bootstrap-правил вне lookback первых двух окон нет.
|
||
|
||
**Mandatory content replication.** Каждый узел Montana обязан хранить текущую версию книги Montana как persistent blob по (genesis_content_app_id, genesis_content_data_hash). При Fast Sync новый узел загружает genesis content как часть обязательной начальной синхронизации (см. раздел Fast Sync).
|
||
|
||
#### Открытый вход узлов
|
||
|
||
Вход узла в консенсус — открытый. VDF 13 000 окон + кандидатура + selection event. Никаких приглашений, никаких разрешений.
|
||
|
||
**Шаг 1: Свободный вход.** Кандидат создаёт аккаунт (OpenAccount), подключается к gossip через account keypair (IBT уровень 3), получает TimeChain values из proposals, вычисляет candidate VDF 13 000 окон от init:
|
||
|
||
```
|
||
candidate_vdf_init = SHA-256("mt-candidate-vdf-init" || timechain_value(W_start) || node_id)
|
||
```
|
||
|
||
W_start — окно начала VDF (заявляется кандидатом в NodeRegistration).
|
||
|
||
**Шаг 2: Кандидатура.** После завершения VDF кандидат публикует NodeRegistration:
|
||
|
||
```
|
||
NodeRegistration:
|
||
type 1B <- 0x11 NodeRegistration
|
||
suite_id 2B
|
||
node_pubkey 897B
|
||
operator_account_id 32B
|
||
proof_endpoint 32B <- endpoint после 13 000 окон VDF
|
||
W_start 8B <- окно начала VDF
|
||
signature 666B
|
||
Итого: ~1 638 B
|
||
```
|
||
|
||
NodeRegistration — ControlObject. При cementing → запись в Candidate Pool. Кандидат ожидает selection event.
|
||
|
||
Валидация NodeRegistration:
|
||
|
||
1. Подпись FN-DSA-512 валидна для node_pubkey
|
||
2. node_id = SHA-256("mt-node" || node_pubkey) уникален (нет в Node Table и Candidate Pool)
|
||
3. operator_account_id существует в Account Table и `is_node_operator == 0`
|
||
4. W_start >= current_window - 2 × τ₂_windows
|
||
5. proof_endpoint верифицируем: пересчёт VDF от `SHA-256("mt-candidate-vdf-init" || timechain_value(W_start) || node_id)` через `effective_vdf_length(W_start)` окон (adaptive VDF)
|
||
|
||
Верификация: `effective_vdf_length(W_start)` сегментов VDF проверяются параллельно. На C ядрах: ~(effective_vdf_length/C) × t_segment.
|
||
|
||
**Шаг 3: Selection event.** Каждые 369 окон сеть выбирает кандидатов из Candidate Pool:
|
||
|
||
```
|
||
selection_windows = { W : W % 369 == 0 }
|
||
slots(W) = max(1, floor(active_nodes(W) / 130))
|
||
candidates(W) = все записи Candidate Pool где expires > W
|
||
sort_key(candidate) = SHA-256(timechain_value(W) || candidate.node_id)
|
||
selected(W) = первые slots(W) кандидатов по sort_key
|
||
```
|
||
|
||
Детерминированно, верифицируемо. Каждый узел вычисляет один и тот же результат. timechain_value(W) неизвестен до окна W — grinding node_id бесполезен.
|
||
|
||
**Шаг 4: Регистрация.** Выбранные кандидаты → Node Table:
|
||
|
||
```
|
||
start_window = W (окно selection event)
|
||
chain_length = 1
|
||
last_confirmation_window = 0
|
||
```
|
||
|
||
Узел добавляется в Node Table с chain_length = 1 (позиция активации). Каждое последующее окно с cemented BundledConfirmation инкрементирует chain_length. Оператор-аккаунт получает `is_node_operator = 1`. Запись удаляется из Candidate Pool.
|
||
|
||
**Expiry.** Кандидатура истекает через 3τ₂ (39 000 окон). Запись удаляется из Candidate Pool автоматически.
|
||
|
||
**Sybil-защита (четыре уровня):**
|
||
|
||
1. **VDF-барьер:** 13 000 окон последовательного хэширования (при нормальной нагрузке). Физическая работа, sequential по построению — не ускоряется параллелизмом.
|
||
|
||
2. **Adaptive VDF:** стоимость кандидатуры пропорциональна давлению на сеть. Сеть видит давление мгновенно (pending_candidates в canonical state). Рост защиты — мгновенный, снятие — медленное (через expiry 3τ₂).
|
||
|
||
```
|
||
candidate_pressure = pending_candidates / active_nodes
|
||
|
||
if candidate_pressure > 0.01:
|
||
effective_vdf_length = 13000 × candidate_pressure × 100
|
||
else:
|
||
effective_vdf_length = 13000
|
||
```
|
||
|
||
| Ситуация | pending | active | pressure | effective_vdf |
|
||
|----------|---------|--------|----------|---------------|
|
||
| Нормальная | 5 | 1 000 | 0.5% | 13 000 окон |
|
||
| Умеренная | 20 | 1 000 | 2% | 26 000 окон |
|
||
| Высокая | 100 | 1 000 | 10% | 130 000 окон |
|
||
| Атака | 1 000 | 1 000 | 100% | 1 300 000 окон |
|
||
| Массовая атака | 100 000 | 1 000 | 10000% | 130 000 000 окон |
|
||
|
||
`effective_vdf_length` фиксируется для кандидата в момент W_start. Валидатор проверяет proof_endpoint через `effective_vdf_length(W_start)`, вычисленный из canonical state на окно W_start. Изменение давления после W_start не влияет на уже считающихся кандидатов.
|
||
|
||
Self-correcting: чем сильнее давление → тем длиннее VDF → тем дороже каждый Sybil → давление падает. При снижении давления → pending уменьшается через expiry (3τ₂) → effective_vdf нормализуется → легитимный вход восстанавливается.
|
||
|
||
**Timing window (known limitation).** Атакующий может начать VDF при низком давлении (effective_vdf = 13 000) и подать NodeRegistration после завершения, когда давление уже высокое. Его proof валиден для effective_vdf(W_start). Первая волна кандидатов, начатых при низком давлении, проходит со стандартным VDF. Вторая волна (начатая при высоком давлении) заблокирована adaptive VDF. Impact ограничен: (a) selection rate limit пропускает max active/130 за event; (b) candidate_expiry = 3τ₂ ограничивает окно подачи; (c) weighted mechanisms (chain_length = 1 при входе) ограничивают влияние вошедших Sybil-узлов на quorum и лотерею.
|
||
|
||
3. **Selection rate limit:** max(1, active_nodes/130) за 369 окон. Массовый вход ограничен. Минимум 1 кандидат всегда проходит.
|
||
|
||
4. **Weighted механизмы:** chain_length определяет вес в quorum (безопасность). lottery_weight (snapshot 6τ₂ + seniority bonus) определяет вес в лотерее (эмиссия). Новые узлы начинают с минимальным влиянием. Время — единственный путь к весу.
|
||
|
||
#### Создание аккаунта
|
||
|
||
Аккаунт создаётся свободно. Пользователь генерирует FN-DSA-512 keypair → вычисляет account_id = SHA-256("mt-account" || suite_id || pubkey) → публикует OpenAccount → операция cemented → запись появляется в Account Table при settle.
|
||
|
||
Sybil-барьер для аккаунтов: account_age определяет приоритет операций. Новый аккаунт — бакет 0, 1 операция за τ₁. Рост приоритета = время. Пустые аккаунты бесполезны — без баланса операции невозможны.
|
||
|
||
#### Скорость роста сети
|
||
|
||
Узлы: selection event каждые 369 окон, slots = max(1, active_nodes/130). Рост ограничен selection rate:
|
||
|
||
```
|
||
Genesis (1 узел): 1 новый узел за 369 окон
|
||
active_nodes = 100: 1 новый узел за 369 окон
|
||
active_nodes = 1 000: 10 новых узлов за 369 окон
|
||
active_nodes = 10 000: 100 новых узлов за 369 окон
|
||
```
|
||
|
||
Каждый кандидат проходит 13 000 окон VDF. Первые кандидаты появляются через 13 000 окон после genesis.
|
||
|
||
Аккаунты: создаются свободно через OpenAccount. Рост пользовательской базы определяется распространением TimeCoin.
|
||
|
||
---
|
||
|
||
## Потоковая модель
|
||
|
||
Операции аккаунтов текут непрерывно. Узел получает операцию → проверяет подпись FN-DSA-512 и баланс (против settled state W-1) → передаёт в P2P gossip. Confirmers (~100 узлов с наибольшим chain_length) собирают операции за окно и публикуют BundledConfirmation.
|
||
|
||
Операция проходит два состояния:
|
||
- **Cemented** (quorum event): 67% active_chain_length подтвердили. Операция необратима. Баланс ещё не обновлён.
|
||
- **Settled** (конец окна, apply at window close): все cemented операции окна применены к Account Table батчем. Баланс обновлён. state_root зафиксирован в proposal.
|
||
|
||
Два параллельных процесса:
|
||
- **Операции** подтверждаются непрерывно через confirmations (cement), применяются батчем в конце окна (settle)
|
||
- **Часы** тикают по расписанию окон τ₁ (TimeChain, лотерея, TimeCoin)
|
||
|
||
Кошелёк получателя отображает входящий перевод в два этапа: «confirmed» после cement (quorum event), «settled» после apply at window close (apply at window close). Между cement и settle операция уже необратима — различие только для UX индикации.
|
||
|
||
Цепочки аккаунтов полностью независимы. Операции разных аккаунтов обрабатываются параллельно без конфликтов.
|
||
|
||
---
|
||
|
||
## Временные слои (τ)
|
||
|
||
```
|
||
τ₁ = 1 window → τ₂ = 13 000 windows
|
||
```
|
||
|
||
Одно окно — τ₁. Всё остальное — производные в window counts.
|
||
|
||
### τ₁ — Окно (D хэшей)
|
||
|
||
Единственная единица канонического времени протокола. Регистрация одного окна Montana Time и эмиссия.
|
||
|
||
- TimeChain продвигается на `D` хэшей
|
||
- NodeChain: chain_length инкрементируется при cemented BundledConfirmation
|
||
- Операции аккаунтов подтверждаются непрерывно через confirmations (cement), применяются батчем в конце окна (settle)
|
||
- control_set: все cemented ControlObjects из окон (previous_proposal.window, current_window] (каноничен)
|
||
- Confirmers (~100) публикуют BundledConfirmation (операции текущего окна + VDF_Reveals предыдущего окна)
|
||
- Кандидаты (~12) публикуют VDF_Reveal с lottery endpoint = SHA-256(T_r || node_id || window_index); reveals цементируются через BundledConfirmation следующего окна
|
||
- Лотерея: `ticket_i = -ln(endpoint_i / 2^256)`, winner = argmin(weighted_ticket) среди cemented VDF_Reveal nodes + cemented account operations
|
||
- Winner_{W-1} определяется proposer_W (= winner_{W-2}) из cemented VDF_Reveals окна W-1 и cemented account operations окна W-1
|
||
- Proposer (proposer_node_id) публикует подписанный proposal
|
||
|
||
- Финальность proposal: подпись proposer_node_id на proposal header. Каждый валидатор применяет control_set + TimeCoin детерминированно и проверяет state_root
|
||
- TimeCoin: регистрация одного окна Montana Time (13 Ɉ) → победителю
|
||
- Supply audit: суммарная эмиссия TimeCoin от генезиса сверяется с `supply(window_index) = 13 × (window_index + 1) Ɉ`
|
||
- Разрешение форков: приоритет ветки с наибольшим суммарным TimeChain-доказательством
|
||
|
||
TimeChain safety: компрометация значения TimeChain требует нарушения свойства последовательности SHA-256 VDF.
|
||
|
||
TimeChain liveness: задержка продвижения TimeChain невозможна — TimeChain вычисляется каждым узлом независимо.
|
||
|
||
### τ₂ — Адаптация (13 000 windows)
|
||
|
||
- Адаптация D через participation-ratio feedback (см. ниже)
|
||
- Snapshot account_chain_length: для каждого аккаунта `account_chain_length_snapshot = account_chain_length`. Snapshot используется лотереей аккаунтов в течение следующего τ₂. Детерминированно для всех узлов
|
||
- Pruning Account Table: удаление пустых аккаунтов без активности 4τ₂ (52 000 окон) с обновлением 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. Удалить запись N из Node Table
|
||
3. Пересчитать node_root
|
||
- Supply audit (sanity check): Σ balance(account) для всех аккаунтов = 13_000_000_000 × (window_index + 1) nɈ
|
||
- Криптографическая амнезия: подписанные proposals сохраняются навсегда — верифицируемая цепочка state commitments. Proposals доказывают что конкретное состояние было закоммичено proposer-узлом; восстановление содержимого состояния требует snapshot или архива
|
||
- Пересчёт параметра D через participation-ratio feedback
|
||
|
||
#### Адаптация D через participation-ratio feedback
|
||
|
||
D адаптируется на границе τ₂ через каноническое chain observation — долю активного chain_length-а, успевшего подписать BundledConfirmation в каждом окне предыдущего τ₂.
|
||
|
||
**Канонический вход:**
|
||
|
||
```
|
||
participation_ratio(W) = cemented_chain_length(W) / active_chain_length(W)
|
||
```
|
||
|
||
Где `cemented_chain_length(W)` — суммарный chain_length узлов, чьи BundledConfirmation для окна W попали в cemented set; `active_chain_length(W)` — суммарный chain_length узлов с `active(node, W) = true`. Оба числа канонически вычисляются каждым узлом bit-exact из Node Table и cemented sets.
|
||
|
||
**Формула адаптации на τ₂ boundary:**
|
||
|
||
```
|
||
median_ratio = median(participation_ratio(W) for W in последние 13 000 окон)
|
||
|
||
Если median_ratio >= 0.95: D_new = D_old × 1.03 (+3%, сеть в комфорте, ускоряемся)
|
||
Если median_ratio <= 0.85: D_new = D_old × 0.97 (-3%, сеть под давлением, замедляемся)
|
||
Иначе (dead zone): D_new = D_old (zone comfort, D не трогаем)
|
||
```
|
||
|
||
**Семантика.**
|
||
|
||
- `median_ratio >= 0.95`: большинство активных узлов легко успевают подписать каждое окно. У сети есть запас производительности — D можно поднять, окно станет чуть длиннее в единицах работы, TimeCoin эмиссия замедляется в физическом времени, но сеть укрепляет запас прочности.
|
||
- `median_ratio <= 0.85`: значительная часть активных узлов не успевает подписать. Сеть близка к границе жизнеспособности — D нужно уменьшить, окно становится короче в единицах работы, медленные узлы получают шанс догнать медиану.
|
||
- Dead zone 0.85-0.95: естественные колебания, D не адаптируется. Это защита от реактивной волатильности.
|
||
|
||
**Свойства.**
|
||
|
||
- **Канонически детерминировано.** participation_ratio вычисляется из canonical cemented sets и Node Table. Два честных узла получают одно и то же значение bit-exact.
|
||
- **Опирается только на canonical chain observations.** Все входные данные формулы — cemented sets и Node Table, оба детерминированы. Corollary I-3.a соблюдён.
|
||
- **Медленная реакция.** Adjustment rate ±3% за τ₂ делает стратегическую манипуляцию через withholding confirmations экономически нерациональной: actor-у с 10% chain_length-а для сдвига D на 2x требуется систематически saboтировать свои подписи ~24 эпохи, теряя все свои TimeCoin награды в этот период.
|
||
- **Dead zone защищает от флуктуаций.** Случайные колебания participation_ratio в диапазоне 0.85-0.95 не вызывают adaptation.
|
||
- **Interleaving на 1 ядре — ожидаемый источник participation_ratio < 1.0.** Узел делит одно ядро между TimeChain VDF и validation; контекстные переключения систематически приводят к пропуску отдельных окон. Это нормальное поведение 1-ядерной архитектуры, не деградация сети. Dead zone 0.85-0.95 поглощает типичный interleaving overhead; feedback ниже 0.85 автоматически уменьшает D, возвращая validation-у пропорционально больший кусок wall-clock времени. Реализации не должны трактовать participation_ratio < 1.0 как отклонение и менять active predicate или пороги cementing в ответ.
|
||
- **Естественное следование hardware progress.** Если железо ускоряется, медианные узлы начинают успевать с запасом, median_ratio поднимается выше 0.95, D растёт, окно нормализуется. Сеть автоматически адаптируется к ожидаемому hardware evolution без явного measurement.
|
||
- **Нет stремления к hard fork по дизайну.** Continuous adaptation в рамках speech-first принципа устраняет необходимость периодического hard fork как запрограммированного события.
|
||
|
||
**Threat model:**
|
||
|
||
- Actor с <20% chain_length-а экономически не может сдвинуть median_ratio значимо.
|
||
- Hyperscaler с 15% узлов может систематически снижать median_ratio на ~15%, но только теряя свои награды. При clamp ±3% за τ₂ максимальный сдвиг D за 24 τ₂ составляет ±1.03^24 ≈ ±103%, что ограничено при правильном выборе `D₀` с запасом.
|
||
- Координированная атака узлов с >50% chain_length эквивалентна атаке на весь консенсус и не рассматривается в рамках локальной защиты participation_ratio.
|
||
|
||
**Genesis parameters:**
|
||
|
||
```
|
||
D₀ = 13 000 000 000 (13 × 10⁹)
|
||
participation_dead_zone_low = 0.85
|
||
participation_dead_zone_high = 0.95
|
||
d_adjustment_rate = 0.03 (±3% за τ₂)
|
||
```
|
||
|
||
Параметр D₀ фиксируется в Genesis Decree. Остальные константы закреплены в протокольных параметрах и могут быть изменены только через protocol version upgrade (software hard fork), не через runtime mechanism.
|
||
|
||
---
|
||
|
||
## Консенсус — Proof of Time (PoT)
|
||
|
||
### Четыре цепочки
|
||
|
||
**TimeChain** — глобальные часы. Чистая VDF-цепочка `T_r = SHA-256^D(T_{r-1})`. Первичный продукт протокола. Источник времени и случайности. Продвигается по расписанию окон.
|
||
|
||
**NodeChain** — последовательность cemented BundledConfirmation конкретного node_id. chain_length — позиция узла в NodeChain: = 1 при активации, +1 при каждом cemented BundledConfirmation. Инвариант: chain_length ≥ 1. Доказывает присутствие узла.
|
||
|
||
**Account** — состояние счёта. Операции финализируются непрерывно через подтверждения (67% active_chain_length). ControlObjects включаются в proposal (каноничен).
|
||
|
||
Зависимости односторонние: TimeChain → NodeChain → AccountChain → AccountTable. Отказ в AccountTable не останавливает часы. Отказ конкретного узла в NodeChain не заражает общий ритм.
|
||
|
||
### Лотерея
|
||
|
||
Лотерея объединяет два класса участников: узлы (через VDF_Reveal с каноническим endpoint) и аккаунты (через AccountChain). Каждый класс производит weighted ticket по длине своей цепочки. Lowest weighted_ticket из объединённого множества побеждает.
|
||
|
||
**Узлы** автоматически участвуют в каждом окне:
|
||
```
|
||
ticket_node = -ln(endpoint_node / 2^256)
|
||
lottery_weight = chain_length_snapshot + min(chain_length / 69, chain_length_snapshot)
|
||
weighted_ticket_node = ticket_node / lottery_weight
|
||
```
|
||
|
||
**Аккаунты** участвуют в окне с финализированной операцией:
|
||
```
|
||
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 калиброван на ~13 кандидатов за окно (включая оба класса). Из кандидатов побеждает lowest weighted_ticket.
|
||
|
||
**Стимул узла:** каждое окно с опубликованным BundledConfirmation увеличивает chain_length → увеличивает шанс победы. Пропущенное окно — это окно не входит в chain_length. Узел остаётся в Node Table и продолжает участвовать.
|
||
|
||
**Стимул аккаунта:** каждое окно с операцией увеличивает account_chain_length → реальный (хоть и редкий) шанс выиграть 13 Ɉ за активность в Montana.
|
||
|
||
### Победитель τ₁
|
||
|
||
Победитель определяется после закрытия окна τ₁. Lowest weighted_ticket из всех кандидатов (узлов и аккаунтов) = победитель.
|
||
|
||
**Если победил узел:**
|
||
- Записывает TimeChain value
|
||
- Operator account узла получает 13 Ɉ TimeCoin
|
||
- Коммитит State Root
|
||
- Формирует proposal (control_set + State Root + TimeCoin), подписывает node_pubkey
|
||
|
||
**Если победил аккаунт:**
|
||
- Аккаунт получает 13 Ɉ TimeCoin (winner_account.balance += 13_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, proposal}`.
|
||
|
||
Верификация lottery endpoint: один SHA-256 — O(1).
|
||
|
||
Верификация proposal: независимое применение control_set + TimeCoin и сравнение state_root.
|
||
|
||
### Устойчивость
|
||
|
||
- **Остановка TimeChain** исключена: каждый узел вычисляет VDF независимо
|
||
- **Искажение TimeChain** исключено: VDF последователен, результат детерминирован
|
||
- **Proposer grinding** исключён: control_set каноничен, state transition детерминирован, операции финализируются независимо от победителя
|
||
- **Front-running** исключён: операции финализируются через подтверждения (quorum event), proposer фиксирует frozen view
|
||
- **Предвычисление** исключено: seed содержит текущее значение TimeChain
|
||
- **Replay** исключён: TimeChain уникален для каждого τ₁
|
||
- **Аппаратное преимущество** ограничено: последовательное хэширование масштабируется тактовой частотой, не количеством ядер
|
||
- **Sybil-барьер**: 13 000 окон VDF + selection event (max 1% active_nodes за 369 окон) + 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 13 окон, затем обе отклоняются. См. раздел «Двойная трата».
|
||
|
||
**Невалидный proposal**: валидаторы отклоняют, fallback на следующего кандидата. Победитель теряет TimeCoin за это окно.
|
||
|
||
**Два proposal от одного proposer_node_id в одном окне**: оба отклоняются (equivocation), fallback к следующему узлу-кандидату. Если этот узел был winner (winner_class=1), он теряет TimeCoin.
|
||
|
||
---
|
||
|
||
## Адреса и переводы
|
||
|
||
### Полный флоу перевода
|
||
|
||
```
|
||
1. Боб: OpenAccount → cemented (quorum event) → 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 подтвердили → операция необратима (quorum event)
|
||
Кошелёк Боба отображает «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 000 mɈ = 1 000 000 μɈ = 1 000 000 000 nɈ
|
||
|
||
Одно окно τ₁ регистрирует одну единицу Montana Time = 13 Ɉ. Число 13 — фиксированная константа протокола эмиссии за окно.
|
||
|
||
Точность: 9 знаков после запятой. Все расчёты эмиссии в nɈ (целочисленная арифметика, без плавающей точки).
|
||
|
||
### Issuance schedule
|
||
|
||
Одно окно Montana Time порождает 13 Ɉ. С первого окна и навсегда.
|
||
|
||
| Параметр | Значение |
|
||
|----------|----------|
|
||
| Genesis | window_index = 0 |
|
||
| TIME_RECORD | 13 000 000 000 nɈ (13 Ɉ за окно) |
|
||
|
||
### Регистрация окна
|
||
|
||
```
|
||
time_record(window_index) = 13_000_000_000 nɈ
|
||
```
|
||
|
||
Каждое окно τ₁ регистрирует одно каноническое окно Montana Time = 13 Ɉ. Без халвингов, без фаз, без исключений. Одна константа на весь горизонт существования протокола.
|
||
|
||
### Supply audit
|
||
|
||
```
|
||
supply(window_index) = 13_000_000_000 × (window_index + 1) nɈ
|
||
```
|
||
|
||
Эмиссия за прошедшее окно: proposal_W зачисляет 13 Ɉ за окно W-1 (Lookback Leadership — winner_{W-1} определяется при cementing proposal_W). После cementing proposal_W суммарно зачислено окна от 0 до W-1, supply = 13 × (W + 1) Ɉ. Одно умножение. Проверяемо каждым узлом в каждом τ₁. O(1).
|
||
|
||
### Инфляция
|
||
|
||
Supply растёт линейно по window_index. Инфляция за окно W:
|
||
|
||
```
|
||
inflation(W) = 1 / W
|
||
```
|
||
|
||
Монотонно убывает, асимптотически стремится к нулю. Чистая арифметика от window_index.
|
||
|
||
### Раннее участие
|
||
|
||
Эмиссия постоянна: 13 Ɉ за каждое окно, с первого окна и навсегда. Вероятность победы пропорциональна весу. Узел, работающий дольше, побеждает чаще. Два узла, запустившиеся одновременно, имеют равные шансы независимо от капитала. Узел, запустившийся раньше, имеет преимущество — он доказал больше окон присутствия.
|
||
|
||
Стимул для ранних участников встроен в арифметику: не бонусы, не множители — просто больший вес.
|
||
|
||
### Распределение
|
||
|
||
Победитель окна τ₁ — узел или аккаунт — регистрирует одно окно Montana Time и получает 13 Ɉ TimeCoin в своей цепочке. Одно правило. Неизменно с генезиса.
|
||
|
||
Узлы и аккаунты конкурируют в единой лотерее. Узлы доминируют статистически из-за непрерывного присутствия — chain_length растёт каждое окно, weighted_ticket систематически ниже. Аккаунты получают долю эмиссии пропорционально своей активности — account_chain_length растёт с каждым окном с операцией. Время — единственный арбитр.
|
||
|
||
Базовый бюджет: 13 Ɉ/τ₁ (регистрация одного окна Montana Time). Реальный бюджет безопасности в покупательной способности зависит от рынка.
|
||
|
||
13 Ɉ за окно — каноническая константа эмиссии Montana Time. Покупательная способность определяется рынком, а не протоколом.
|
||
|
||
#### Двигатель роста сети
|
||
|
||
Участие аккаунтов в лотерее создаёт flywheel роста сети:
|
||
|
||
```
|
||
Активные пользователи в приложениях → AccountChain растёт → шансы в лотерее
|
||
↓ ↓
|
||
Приложения привлекают пользователей Иногда выигрывают TimeCoin
|
||
↓ ↓
|
||
Разработчики хотят пользователей Дополнительная мотивация активности
|
||
↓ ↓
|
||
Разработчики запускают узлы Montana Больше операций в сети
|
||
↓ ↓
|
||
Узлы зарабатывают TimeCoin Сеть растёт и децентрализуется
|
||
↓ ↓
|
||
Финансирование развития инфраструктуры → больше пропускной способности → лучше для приложений
|
||
```
|
||
|
||
Эмиссия 13 Ɉ за окно одна и та же, но финансирует обе стороны одновременно: узлы (поддержание сети) и активные пользователи (использование сети). Они взаимно усиливают друг друга — циркулярная экономика.
|
||
|
||
---
|
||
|
||
## Пропускная способность
|
||
|
||
Размер Transfer: ~779 B (открытый перевод, FN-DSA-512 подпись).
|
||
|
||
| Канал узла | TPS |
|
||
|-----------|-----|
|
||
| 10 Mbps | ~1 600 |
|
||
| 100 Mbps | ~16 000 |
|
||
| 1 Gbps | ~160 000 |
|
||
|
||
---
|
||
|
||
## Хранение
|
||
|
||
### Состояния операции (UX)
|
||
|
||
Операция проходит два различимых состояния:
|
||
|
||
```
|
||
publish ──→ cement (quorum event) ──→ settle (apply at window close)
|
||
"confirmed" "settled"
|
||
```
|
||
|
||
- **Cemented (quorum event):** 67% active_chain_length подтвердили операцию через BundledConfirmation. Операция необратима и гарантированно будет применена в конце окна. Wallet показывает «confirmed».
|
||
- **Settled (apply at window close, в конце окна):** все cemented операции окна применены батчем к Account Table в детерминированном порядке. account_root зафиксирован в proposal. Wallet показывает «settled».
|
||
|
||
Между cement и settle операция уже необратима — настройка двух UI-состояний нужна только для индикации завершённости state transition. Зависимые операции (Transfer на только что созданный аккаунт) сериализуются по окнам через confirmer dependency rule, поэтому cemented операция гарантированно settle-ится.
|
||
|
||
### Модель: глобальное состояние + локальная история
|
||
|
||
Узлы хранят глобальное состояние (Account Table, Node Table, Candidate Pool, proposals). Тела операций аккаунтов хранятся у владельцев. После settle (apply at window close) state transition применён — балансы в таблице обновлены, тело операции сети больше не нужно.
|
||
|
||
### Два участника
|
||
|
||
**Узел** — мой компьютер (десктоп, сервер, VPS), 24/7, минимум 1 ядро:
|
||
|
||
```
|
||
Consensus (протокольный слой):
|
||
Account Table (account_id, balance, frontier_hash, pubkey)
|
||
+ persistent sparse Merkle tree (account_root)
|
||
Node Table (node_id, pubkey, start_window, chain_length)
|
||
+ persistent sparse Merkle tree (node_root)
|
||
Candidate Pool (node_id, pubkey, operator, proof_endpoint, W_start, expires)
|
||
+ persistent sparse Merkle tree (candidate_root)
|
||
Proposals (навсегда)
|
||
TimeChain VDF + валидация (1 ядро, 24/7, validation interleaved)
|
||
P2P gossip (операции, confirmations, reveals, proposals)
|
||
|
||
Данные владельца (клиентский слой):
|
||
Локальное хранилище (фото, файлы, бэкапы сообщений — зашифровано)
|
||
Почтовый ящик (входящие сообщения пока телефон офлайн)
|
||
```
|
||
|
||
Узел принадлежит оператору. Оператор решает что хранить помимо consensus state. Consensus state обязателен — без него узел не участвует в сети. Данные владельца — решение клиентского слоя: формат, шифрование, объём, retention.
|
||
|
||
**Ядра и производительность.** TimeChain VDF — sequential по построению; дополнительные ядра не ускоряют продвижение TimeChain. Второе ядро изолирует validation от VDF-цикла и устраняет interleaving overhead (пропуск окон ~5-10% при нагрузке). Узлы с 1 ядром полностью участвуют в консенсусе; узлы с 2+ ядрами имеют bounded преимущество в participation_ratio, ограниченное сверху interleaving overhead. Participation-ratio feedback на τ₂-boundary автоматически подстраивает D под фактическое железо медианы сети.
|
||
|
||
**Телефон (кошелёк)** — клиент моего узла, онлайн когда используется:
|
||
|
||
```
|
||
Хранит:
|
||
Свои ключи (seed → keypairs)
|
||
Локальная история (операции, сообщения — для UX)
|
||
|
||
Делает:
|
||
Подключается к своему узлу
|
||
Отправляет/получает переводы через узел
|
||
Читает/пишет данные на свой узел
|
||
Забирает сообщения из почтового ящика узла
|
||
```
|
||
|
||
Потеря телефона: seed восстанавливает ключи, баланс в Account Table публичен, данные на узле целы. Потеря узла: seed восстанавливает аккаунт, consensus state скачивается через Fast Sync. Данные владельца (фото, сообщения) — ответственность оператора (бэкап, RAID, репликация между своими узлами — клиентский слой).
|
||
|
||
Привязка телефона к узлу, авторизация, синхронизация, формат хранения данных — клиентский слой. Протокол предоставляет identity (account_id ↔ operator_account_id) как основу для привязки.
|
||
|
||
### Размеры
|
||
|
||
| Участник | Данные | Размер |
|
||
|----------|--------|--------|
|
||
| Узел (1M аккаунтов) | Account Table + Node Table + Candidate Pool + Proposals | ~2 GB |
|
||
| Узел (10M аккаунтов) | Account Table + Node Table + Candidate Pool + Proposals | ~11 GB |
|
||
| Узел (100M аккаунтов) | Account Table + Node Table + Candidate Pool + Proposals | ~101 GB |
|
||
| Кошелёк (обычный) | ~100 операций за 26 τ₂ + контакты + сообщения | ~1 MB |
|
||
| Кошелёк (активный) | ~10 000 операций за 26 τ₂ | ~16 MB |
|
||
| Корпорация | ~1M Anchor за 26 τ₂ | ~0.8 GB |
|
||
|
||
### Потеря данных клиента
|
||
|
||
Потеря телефона: seed восстанавливает ключи, баланс в Account Table публичен, данные на узле целы — полное восстановление. Потеря узла: seed восстанавливает аккаунт, consensus state — через Fast Sync. Данные владельца (фото, сообщения) — ответственность оператора. Бэкап, RAID, репликация между своими узлами — решения клиентского слоя.
|
||
|
||
### Fast Sync (новый узел)
|
||
|
||
1. Цепочка proposals от генезиса — проверка TimeChain-цепочки и подписей proposer-узлов (мегабайты)
|
||
2. Snapshot трёх таблиц (Account Table + Node Table + Candidate Pool) от пиров на момент окна W (произвольное недавнее окно)
|
||
3. Reconstructed `account_root`, `node_root` и `candidate_root` сравниваются с соответствующими полями из proposal окна W. Все три совпадают → snapshot валиден. Проверка `state_root = SHA-256("mt-state-root" || node_root || candidate_root || account_root)` — дополнительный integrity check.
|
||
4. Catch-up после окна W до текущего:
|
||
- Запросить cemented UserObjects и применить их батчем к Account Table по алгоритму apply at window close (включая проверку prev_hash и баланса).
|
||
- Запросить cemented ControlObjects (NodeRegistration) и применить их к Candidate Pool в детерминированном порядке. Применить selection events.
|
||
- Выполнить incremental update Merkle trees (account_root, node_root, candidate_root) для отражения changes.
|
||
- На каждом промежуточном proposal сверять локальный state_root с заявленным в proposal header
|
||
5. **Genesis content.** `genesis_content_data_hash` зафиксирован в Genesis Decree как протокольная константа. Загрузка книги Montana по этому хэшу — конвенция reference implementation. Формат загрузки и верификации определяется клиентским слоем.
|
||
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 — длинная активная цепочка даёт реальные шансы выиграть 13 Ɉ
|
||
- Ничего не привязано к конкретному приложению — seed принадлежит пользователю, account_id переходит между приложениями без потери истории
|
||
|
||
**Нулевая стоимость переключения приложений.** AccountChain пользователя — его собственность. Если приложение закрылось или пользователь хочет уйти — account_id, баланс, история и накопленный account_chain_length остаются. Пользователь продолжает в другом приложении на том же протоколе. Приложения вынуждены конкурировать качеством, а не замком.
|
||
|
||
### Двигатель роста сети через AccountChain
|
||
|
||
Лотерея Montana объединяет два класса участников: узлы (через VDF_Reveal с каноническим endpoint) и аккаунты (через 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
|
||
- каждая содержит T_r текущего окна (endpoint field)
|
||
- суммарный 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: проверить endpoint = T_r окна W, подтвердить chain_length из Node Table
|
||
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 байта — доказательство что набор сообщений существовал на конкретном window_index. Подделать историю переписки невозможно — хэш не совпадёт.
|
||
|
||
**Архив документов.** Компания ежедневно записывает Merkle root документов. Через 10 лет регулятор спрашивает «существовал ли документ X на дату Y». Компания предоставляет документ, Merkle proof и ссылку на proposal. Верификация математическая.
|
||
|
||
**Социальная сеть.** Каждый пост привязан к Montana Time через Anchor. Порядок публикаций доказуем. Редактирование не скрывает оригинал — хэш оригинала уже в цепочке.
|
||
|
||
### Экономика
|
||
|
||
Anchor бесплатен. Тысячи приложений записывающих якоря — утилитарное использование Montana Time. Спрос на токен привязан к утилитарной функции: перевод ценности и запись времени, не спекуляция.
|
||
|
||
Не нужны смарт-контракты. Не нужен Turing-complete язык. Не нужен газ. Не нужны комиссии.
|
||
|
||
### Граница протокола и клиентского слоя
|
||
|
||
Протокол предоставляет три примитива: время (window_index), ценность (Transfer), фиксация (Anchor). Всё остальное — хранение данных, мессенджер, discovery контактов, профили, шифрование, репликация контента, форматы файлов — реализуется клиентским слоем. Стандарты совместимости между приложениями определяются в спецификации приложения (Montana App spec), не в протоколе.
|
||
|
||
### Локальное хранилище узла
|
||
|
||
Узел помимо consensus state имеет локальное хранилище произвольных байт. Это инфраструктура реализации, не consensus — содержимое хранилища не входит ни в один root, не проверяется другими узлами, не влияет на участие в консенсусе.
|
||
|
||
Два режима:
|
||
|
||
- **Ephemeral** (TTL = τ₂) — кратковременные данные, удаляются автоматически
|
||
- **Persistent** (TTL = 0) — данные владельца, хранятся бессрочно по решению оператора
|
||
|
||
Формат хранения, индексация, чанкование файлов, протокол обмена данными между узлами, механизмы discovery контента — определяются клиентским слоем (см. Montana App spec).
|
||
|
||
**genesis_content_data_hash** — протокольная константа в Genesis Decree. Хэш манифеста книги Montana v1.0. Загрузка и хранение книги по этому хэшу — конвенция reference implementation, не consensus enforcement. Узел без книги продолжает участвовать в консенсусе.
|
||
|
||
### 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. Проверить endpoint = T_r окна W
|
||
c. Подтвердить chain_length из Node Table
|
||
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, 3b, 5: O(1) операций. Шаг 6: `D` хэшей на одном ядре (один сегмент TimeChain VDF). Шаг 7: линейная проверка подписей и хэшей по цепочке proposals от окна W до genesis.
|
||
|
||
Полная верификация от генезиса: H сегментов TimeChain VDF, каждый независим. На C ядрах: ~(H/C) × D хэшей. TimeChain хранит все промежуточные T_r в proposals — параллелизация полная.
|
||
|
||
---
|
||
|
||
## Ключи
|
||
|
||
### Мнемоника и seed
|
||
|
||
24 слова из словаря мнемоники (2 048 английских слов). 256 бит энтропии + 8 бит checksum.
|
||
|
||
```
|
||
mnemonic: 24 слова
|
||
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 и lottery 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, lottery endpoints, адреса, 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-candidate-vdf-init` | VDF init seed для кандидата на вход в сеть |
|
||
| `mt-merkle-leaf` | Листья Merkle-деревьев |
|
||
| `mt-merkle-node` | Внутренние узлы Merkle-деревьев |
|
||
| `mt-state-root` | Композиция state_root из node_root, candidate_root и account_root |
|
||
| `mt-timechain` | TimeChain VDF seed |
|
||
| `mt-lottery` | Lottery endpoint seed (SHA-256(T_r \|\| node_id \|\| window_index)) |
|
||
| `mt-confirmation` | Хэширование async confirmations |
|
||
| `mt-app` | Деривация app_id для Application Layer |
|
||
| `mt-node` | Деривация node_id |
|
||
| `mt-genesis` | Деривация frontier_hash genesis-аккаунтов |
|
||
| `mt-nodechain-genesis` | (deprecated v28.0.0, ранее NodeChain VDF genesis init) |
|
||
| `mt-seed` | Salt для PBKDF2 деривации seed из мнемоники |
|
||
| `mt-account-key` | Деривация keypair аккаунта из seed |
|
||
| `mt-node-key` | Деривация keypair узла из seed |
|
||
| `mt-account-lottery` | Endpoint AccountChain для лотереи |
|
||
| `mt-content-chunk` | Хэширование чанков контента (клиентский слой) |
|
||
| `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 VDF |
|
||
| State machine | Account Table, Node Table, state transitions |
|
||
| P2P gossip | Распространение операций, confirmations и proposals |
|
||
|
||
### Инфраструктура
|
||
|
||
| Библиотека | Назначение |
|
||
|------------|------------|
|
||
| RocksDB | Хранение Account Table и операций |
|
||
| libp2p | P2P транспорт |
|
||
|
||
Production: Rust.
|
||
|
||
---
|
||
|
||
## Сетевой уровень
|
||
|
||
Все временные параметры сетевого уровня (frame rate, padding window, feeler interval, Dandelion timers) — implementation guidance для локального сетевого стека узла. Они оперируют на локальных часах узла и находятся вне scope consensus state.
|
||
|
||
### 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(current_window_index / 2))
|
||
```
|
||
|
||
Сервер проверяет:
|
||
|
||
1. Подпись валидна для заявленного client_pubkey
|
||
2. Window slot = текущий ИЛИ предыдущий (окно = 2 window_index)
|
||
3. Уровень доступа — сервер проверяет client_pubkey по трём таблицам последовательно, первое совпадение определяет уровень:
|
||
- `node_id = SHA-256("mt-node" || client_pubkey)` в Node Table → **полный gossip** (клиент подключился node keypair)
|
||
- `node_id` с `node_pubkey = client_pubkey` в Candidate Pool → **read-only gossip**: получает proposals (кандидат подключился 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 к конкретному получателю. Window slot ограничивает replay window до 2 окон.
|
||
|
||
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-секундном окне на исходящих
|
||
|
||
Персональный = доступный: 13 исходящих × 1 frame/сек × 1024 bytes = 13 KB/сек ≈ 33 GB/мес. Приемлемо для домашнего сервера.
|
||
|
||
#### Transport Randomness
|
||
|
||
Все рандомизированные решения транспортного уровня (stem routing, frame scheduling, nonce generation) используют CSPRNG из OS entropy pool. Детерминированный PRNG от node state запрещён для transport-layer randomness.
|
||
|
||
Transport obfuscation ортогонален консенсусу. TimeChain, state machine работают поверх любого транспорта без изменений.
|
||
|
||
### Peer Selection
|
||
|
||
Открытый вход с VDF-барьером делает sybil-узлы дорогими: каждый sybil = 13 000 окон VDF (sequential SHA-256, не ускоряется параллелизмом) + selection event. Peer selection использует diversity constraints из протокольных данных (start_window) и сетевых (/16, ASN).
|
||
|
||
P2P gossip — только зарегистрированные и приглашённые узлы (уровни 1-2 IBT, см. Transport Obfuscation → Identity-Bound Tunnel). Аккаунты (уровень 3 IBT) взаимодействуют через свой доверенный узел.
|
||
|
||
#### Исходящие соединения
|
||
|
||
13 исходящих, все полные. Uniform framing скрывает типы сообщений — отдельные relay-only соединения не нужны.
|
||
|
||
Выбор: случайный 50/50 из таблиц «новые» и «проверенные». Бакетирование с секретным ключом узла. Без preference по chain_length — выбор равномерный.
|
||
|
||
#### Четыре уровня diversity
|
||
|
||
Каждый исходящий проверяется по всем четырём constraints:
|
||
|
||
```
|
||
Сетевые:
|
||
/16 — не более 1 исходящего на /16 подсеть (IPv4) или /48 (IPv6)
|
||
ASN — не более 2 исходящих на автономную систему
|
||
|
||
Протокольные:
|
||
start_window — не более 2 исходящих к узлам с start_window в одном τ₂
|
||
```
|
||
|
||
Сетевые constraints: /16 и ASN diversity. Протокольный constraint start_window канонически доступен из Node Table.
|
||
|
||
Следствие: кластер sybil зарегистрированных в один τ₂ → максимум 2 из 13 слотов. Eclipse требует узлы в 7+ разных AS в 7+ разных /16 с регистрацией в 7+ разных τ₂.
|
||
|
||
ASN-карта загружается при запуске. Без карты — 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.** Стебель использует только исходящие соединения — входящие не участвуют. Каждые 693 окна узел выбирает 2 из 13 исходящих как стебельных (stem epoch). Все стебельные операции в эпохе направляются через одного из этих 2 (выбор по hash(msg)).
|
||
|
||
**Применение по типу объекта:**
|
||
|
||
| Объект | Режим | Причина |
|
||
|--------|-------|---------|
|
||
| UserObject (Transfer, Anchor, OpenAccount, ChangeKey) | Stem → fluff | Скрыть IP отправителя |
|
||
| ControlObject (NodeRegistration) | Stem → fluff | Скрыть IP регистрирующегося кандидата |
|
||
| VDF Reveal | Прямой gossip (без stem) | node_id публичен в reveal, анонимность невозможна; IP скрыт Transport Obfuscation (TLS 1.3 на порт 443) |
|
||
| Confirmation | Stem → fluff | Скрыть какой узел подтвердил первым |
|
||
|
||
**Свойства:**
|
||
|
||
| Угроза | Защита |
|
||
|--------|--------|
|
||
| Пир видит IP отправителя | Stem: пир видит только предыдущий hop |
|
||
| Глобальный наблюдатель (ISP) | TLS 1.3 + uniform framing (Transport Obfuscation) |
|
||
| Анализ графа gossip | Операция входит в gossip из случайной точки |
|
||
| Контроль k узлов | Деанонимизация требует контроля O(√n) узлов |
|
||
|
||
**Реализация:**
|
||
|
||
```
|
||
stem_peers = random_sample(outbound, 2) // каждые 693 окна
|
||
|
||
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 распределён по 13 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 start_window + network diversity constraints
|
||
Слой 3: NAT Traversal каждый может войти, даже за NAT
|
||
Слой 4: Censorship-Resistant Discovery четыре канала, достаточно одного
|
||
Слой 5: Dandelion++ пиры не знают кто автор операции
|
||
```
|
||
|
||
Каждый слой закрывает свой вектор. Ни один не требует внешней инфраструктуры. Всё построено поверх libp2p и существующего gossip. Сетевой уровень ортогонален консенсусу — ни один state transition не затронут.
|
||
|
||
---
|
||
|
||
## Эволюция протокола
|
||
|
||
Изменения правил протокола существуют вне consensus state. Эволюция: открытые предложения, независимые реализации, добровольный выбор операторов узлов, 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, как социальный и инженерный процесс над Anchor-публикациями и репозиториями реализаций.
|
||
|
||
### Жизненный цикл изменения
|
||
|
||
```
|
||
1. PROPOSAL
|
||
Любой участник публикует MIP (Montana Improvement Proposal)
|
||
как Anchor с текстом на узле автора:
|
||
app_id = SHA-256("mt-app" || "mips")
|
||
data_hash = H(текст MIP)
|
||
anchor = операция Anchor в AccountChain автора
|
||
|
||
Авторство и timestamp доказуемы через подпись Anchor и
|
||
timechain_value cemented окна. История эволюции навсегда
|
||
через Anchor в 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** структуры — публикующие рекомендации, обзоры, анализ безопасности через Anchor. Их подписи не имеют binding эффекта на consensus, их составы не хранятся в state, их голоса не считаются в state transitions.
|
||
|
||
Примеры advisory структур (опциональны, не часть протокола):
|
||
|
||
- **AI Council** — модели разных компаний публикуют технические обзоры MIPs
|
||
- **Core Council** — публичные эксперты публикуют анализ безопасности и социальную координацию
|
||
|
||
Захват advisory совета не даёт контроля над протоколом — он даёт только возможность опубликовать рекомендацию, которую операторы узлов могут проигнорировать. Это устраняет attack surface governance: нет binding голосования = нет цели для компрометации.
|
||
|
||
Advisory councils организуются вне протокола (репозитории, форумы, Anchor-публикации). Протокол не знает об их существовании и не выделяет им никаких прав.
|
||
|
||
### Параметрическая адаптация
|
||
|
||
Параметры `D` и `m` адаптируются автоматически на границе τ₂ через participation-ratio feedback (см. раздел «Адаптация D через participation-ratio feedback»). Это **не** governance. Адаптация детерминирована, опирается только на canonical chain observations (cemented sets, Node Table), не требует голосования, не требует социальной координации, не зависит от измерений физического мира. Формула адаптации и её параметры зафиксированы в Genesis Decree; правка самой формулы требует MIP + новой версии ПО + adoption через chain_length, как и любое другое изменение протокола.
|
||
|
||
Закрытие окна определяется quorum event в канонических cemented sets. Механизм полностью event-driven и опирается только на canonical state.
|
||
|
||
---
|
||
|
||
## Обоснование протокольных констант
|
||
|
||
Числовая система Montana построена на оси 13 (Змееносец — число вне 12-ричной системы) и последовательности 3-6-9 (числа вне бинарного цикла 1-2-4-8-7-5). Каждая константа имеет символическое и инженерное обоснование.
|
||
|
||
### Числовая ось 13
|
||
|
||
| Константа | Значение | Обоснование |
|
||
|-----------|----------|-------------|
|
||
| D₀ (TimeChain VDF за окно) | 13 × 10⁹ | 13 = Змееносец. Масштаб 10⁹ обеспечивает VDF >> network RTT на commodity CPU (~100 MH/s → окно физически достаточно для gossip propagation) |
|
||
| (m₀ — removed) | — | NodeChain VDF удалён в v28.0.0. Присутствие доказывается через BundledConfirmation, endpoint через SHA-256(T_r \|\| node_id \|\| window_index) |
|
||
| τ₂ (epoch boundary) | 13 000 окон | 13 × 10³. Одна эпоха = одна единица VDF entry. Все процессы длительного действия (pruning, adaptation, snapshot) привязаны к τ₂ |
|
||
| VDF entry (стоимость входа) | 13 000 окон | = τ₂. Кандидат работает ровно одну эпоху до входа. Совпадение τ₂ и VDF entry — feature: единица адаптации = единица входа |
|
||
| timecoin_per_window | 13 Ɉ | 13 на третьем масштабе: D = 13×10⁹, VDF entry = 13×10³, emission = 13×10⁰ |
|
||
|
||
### Последовательность 3-6-9
|
||
|
||
| Константа | Значение | Обоснование |
|
||
|-----------|----------|-------------|
|
||
| selection_interval | 369 окон | 3-6-9 как единое число. Цифровой корень = 9. ~35 selection events за τ₂ — плавный вход новых узлов |
|
||
| stem_epoch (Dandelion++) | 693 окна | Цифровой корень = 9. ~1.9 selection intervals — ротация стебельных peers чаще, чем selection events, для diversity |
|
||
| Ядра на узел | минимум 1 | TimeChain VDF sequential — не ускоряется параллелизмом. 1 ядро достаточно, validation interleaved с VDF. 2+ ядра устраняют interleaving overhead (~5-10%), дают bounded преимущество в participation_ratio |
|
||
|
||
### Инженерные константы
|
||
|
||
| Константа | Значение | Обоснование |
|
||
|-----------|----------|-------------|
|
||
| confirmation_quorum | 67% | Стандартный BFT 2/3+1. 40 лет distributed systems research (PBFT, Tendermint, HotStuff) |
|
||
| confirmation_threshold | active_chain_length / 130 | 130 = 13 × 10. Числовая ось. ~130 confirmers при large-scale сети |
|
||
| outbound connections | 13 | Числовая ось. Больше diversity и relay capacity, чем при 8. Eclipse требует 7+ разных AS/subnet/τ₂ |
|
||
| equivocation timeout | 13 окон | Числовая ось. Окно разрешения equivocation до отклонения обеих операций |
|
||
| active predicate | 2τ₂ (26 000 окон) | Узел мог пропустить одну полную эпоху (downtime, перезагрузка) и вернуться. 1τ₂ — слишком агрессивно. 3τ₂ — мёртвые узлы висят слишком долго |
|
||
| node pruning | 8τ₂ (104 000 окон) | 4× active threshold. Узел неактивен 8 эпох = гарантированно мёртв. Запас позволяет длительный offline без потери записи |
|
||
| pruning_idle (accounts) | 4τ₂ (52 000 окон) | = граница первого бакета аккаунтов (4^1 × τ₂). Consistency с бакетной системой |
|
||
| candidate_expiry | 3τ₂ (39 000 окон) | ~105 selection events. Достаточно для fair chance при конкуренции. 2τ₂ = 70 events (вероятность пропуска выше). 4τ₂ = раздувание Candidate Pool |
|
||
| account бакеты | 4^N × τ₂ | Экспоненциальная шкала. Sybil-атакующий изолирован в бакете 0. Органический рост через 4× расширения на каждом уровне |
|
||
| slots per selection | max(1, active/130) | ~0.77% от сети за event. 130 = 13 × 10. Consistency с confirmation threshold (active_chain_length / 130) |
|
||
| D adjustment rate | ±3% за τ₂ | Медленная реакция: 24 эпохи для удвоения D. Быстрее — withholding атака дешевеет. Медленнее — инертность при hardware shift |
|
||
| dead zone | 0.85 — 0.95 | Ниже 0.85 = 15%+ узлов под давлением. Выше 0.95 = комфорт. Между = нормальные флуктуации, D стабилен |
|
||
| target₀ | calibrated at genesis | Калибруется на ~13 VDF_Reveal кандидатов за окно. При genesis (1 узел): target₀ устанавливается так, чтобы единственный узел гарантированно проходил threshold (weighted_ticket < target₀ для chain_length = 1). Уточняется при testnet |
|
||
| chain_length_snapshot | скользящее окно 6τ₂ (78 000 окон) | Количество cemented BundledConfirmation за последние 6τ₂. Основа lottery_weight. Новый узел через 6τ₂ выходит на равный snapshot со старожилом. Цифровой корень 6 — Tesla |
|
||
| seniority_bonus | min(chain_length / 69, snapshot) | Bounded добавка за longevity. Делитель 69 (цифровой корень 6, Tesla). Cap = snapshot: максимальное преимущество старожила ≈ 2x. Через ~5 лет bonus достигает cap. Далее — стабильный потолок |
|
||
| lottery_weight | snapshot + seniority_bonus | Разделение: lottery_weight для эмиссии (недавняя работа + bounded longevity), абсолютный chain_length для quorum (безопасность). Temporal Aristocracy ограничена cap-ом. Новые участники мотивированы на любой стадии сети |
|
||
| adaptive_vdf_threshold | 1% (pending/active) | Совпадает с selection rate (~0.77% за event). Ниже порога — стандартный VDF. Выше — давление аномальное, защита активируется |
|
||
| adaptive_vdf_multiplier | ×100 | effective_vdf = 13000 × pressure × 100. При 100% давлении VDF в 100 раз длиннее. Self-correcting: стоимость атаки растёт пропорционально давлению |
|
||
|
||
---
|
||
|
||
## Архитектура
|
||
|
||
```
|
||
ТЕЛЕФОН / ДЕСКТОП УЗЕЛ (десктоп / сервер, 24/7)
|
||
┌────────────────────────┐ ┌──────────────────────────────────────┐
|
||
│ Кошелёк │ │ │
|
||
│ FN-DSA-512 keypair │ │ TimeChain │
|
||
│ локальная UX-история │ │ T_r = SHA-256^D(T_{r-1}) │
|
||
│ операций │ │ каноническая последовательность, │
|
||
│ │ │ источник случайности │
|
||
│ AccountChain │ │ │ │
|
||
│ (счётчик окон │ │ ▼ │
|
||
│ активности) │ │ NodeChain (per node) │
|
||
│ │ │ chain_length = cemented │
|
||
└──────────┬─────────────┘ │ BundledConfirmation count │
|
||
│ операции │ доказательство присутствия │
|
||
│ (type|prev_hash| │ lottery endpoint = SHA-256(T_r || │
|
||
│ 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.
|
||
Отказ узла не заражает каноническую последовательность.
|
||
```
|