281 KiB
Монтана — Спецификация сетевого слоя
Версия: 1.0.0 (2026-05-02)
Слой: Network — между Protocol (низкий) и App (высокий).
Введение
Сетевой слой Montana — транспорт и discovery между узлами консенсуса и клиентами. Эта спецификация исторически жила inline разделами в Montana Protocol; отделена в собственный файл для разделения слоёв по принципу [I-7] минимальной криптографической поверхности и удобства независимого аудита.
Что в этой спеке:
- Транспортный слой через libp2p (TCP+TLS 1.3 + Noise XK)
- Обфускация трафика (TLS-mimicry, ECH, padding, timing)
- Identity-Bound Tunnel (IBT) — proof что peer обладает privкey соответствующего его node_id
- Transport Randomness — непредсказуемые network-bound seeds
- PeerRecord и discovery
- Mesh Transport (Bluetooth/Wi-Fi Direct, store-and-forward)
- Sync protocols (FastSync, BatchLookup, RangeSubscribe, Label Rotation)
- Threat Model сетевого слоя
- Binding KAT vectors сетевого слоя
- apply_mesh_frame и apply_store_and_forward — нормативные правила
- Final Gate audit M6 milestone
Что НЕ в этой спеке:
- State machine, apply_proposal, операции (Transfer/OpenAccount/...) — см. Montana Protocol
- Crypto primitives (ML-DSA-65, ML-KEM-768, SHA-256, PBKDF2/HKDF) — см. Montana Protocol §«Криптография»
- UI / Wallet / Messenger / Channels / Contacts / Profile / Junona / Browser — см. Montana App
Сетевой уровень
Все временные параметры сетевого уровня (frame rate, padding window, feeler interval, Dandelion timers) — implementation guidance для локального сетевого стека узла. Они оперируют на локальных часах узла и находятся вне scope consensus state.
Обфускация транспорта
Монтана — персональная сеть. Каждый узел — персональный сервер участника. Транспортный слой построен из этого определения: персональный сервер отвечает только участникам, персональный мессенджер скрывает тайминг сообщений, персональный = доступный обычному человеку.
Шифрование
Все P2P-соединения инкапсулированы в TLS 1.3 на порт 443. Noise framework (встроен в libp2p) для аутентификации по публичному ключу узла внутри TLS. Содержимое трафика недоступно наблюдателю.
Identity-Bound Tunnel (IBT)
Персональный сервер отвечает только участникам сети. После TLS handshake клиент отправляет proof аутентификации. Узлы (зарегистрированные и приглашённые) подписывают node keypair. Аккаунты (клиенты) подписывают account keypair.
proof = ML-DSA-65_sign(client_privkey,
"mt-tunnel-online" || server_node_id || floor(current_window_index / 2))
Сервер проверяет:
- Подпись валидна для заявленного client_pubkey
- Window slot = текущий ИЛИ предыдущий (окно = 2 window_index)
- Уровень доступа — сервер проверяет 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 → 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 от любого валидного ML-DSA-65 ключа (Account Table не проверяется). Для защиты от connection flood клиент прилагает proof-of-work:
SHA-256("mt-bootstrap-pow" || proof || nonce) < target
target подбирается чтобы стоимость ≈ 100ms CPU. PoW требуется только при подключении к bootstrap, не к обычным peers.
Mesh transport IBT extension.
Mesh transport (см. подраздел «Mesh Transport» ниже) работает при отсутствии fresh window_index — устройство может быть offline часы или дни до следующей синхронизации с internet-сетью. IBT proof в mesh контексте использует cached window_index — значение последнего известного окна с любого предыдущего online-соединения.
Формула для mesh transport:
mesh_proof = ML-DSA-65_sign(
client_privkey,
"mt-tunnel-mesh"
|| peer_node_id
|| floor(cached_window_index / 2)
|| mesh_session_nonce)
где:
cached_window_index u32 — последнее известное окно
от любого предыдущего online
handshake или gossiped proposal
mesh_session_nonce 32B — генерируется инициатором
handshake из CSPRNG, передаётся
в plain части mesh advertisement
Acceptable staleness bound. Peer принимает cached_window_index в диапазоне [peer.known_window_index - 7 × τ₁, peer.known_window_index]. Свыше 7 × τ₁ cached значение признаётся слишком старым — peer отклоняет mesh IBT handshake и требует свежее значение через любой доступный канал до продолжения.
Session nonce tracking. Peer хранит used_nonces[sender_pubkey] — set of mesh_session_nonce значений использованных данным sender в пределах acceptable staleness window. При приёме proof с mesh_session_nonce ∈ used_nonces[sender_pubkey] → reject (replay). Set pruning: записи старше 7 × τ₁ удаляются (nonce reuse после expiry acceptable, cached_window_index уже невалиден).
Domain separator обязательно mt-tunnel-mesh, не mt-tunnel-online. Отдельный separator критичен — иначе атакующий перехвативший online IBT proof (window slot = 2 × τ₁ replay) мог бы использовать его в mesh контексте где staleness window расширен до 7 × τ₁. Cross-context replay блокируется на уровне domain separation.
Replay surface analysis.
- Online IBT (separator
mt-tunnel-online): replay window2 × τ₁— узкий, acceptable. - Mesh IBT (separator
mt-tunnel-mesh): replay window расширен до7 × τ₁, но replay блокируется per-nonce tracking. - Cross-context: domain separation делает proof для одного context невалидным в другом.
Verification procedure для mesh peer.
- Parse advertisement, извлечь
sender_pubkey,mesh_session_nonce,proof. - Проверить signature с
sender_pubkey. - Извлечь
cached_window_indexиз proof message reconstruction (peer знает sender_pubkey, peer_node_id известен локально, пробует range[known_window_index - 7 × τ₁, known_window_index]пока не найдёт совпадающее значение; при отсутствии совпадения — reject). - Проверить
mesh_session_nonce ∉ used_nonces[sender_pubkey]. - Всё ok → accept, добавить
mesh_session_nonceв used_nonces, начать mesh сессию. - Любая проверка не прошла → silent reject (no error message, чтобы не давать feedback злоумышленнику).
Uniform Framing
Все сообщения Монтаны внутри IBT-соединения фрагментируются на фреймы фиксированного размера:
frame_size = 1024 bytes
frame format:
flags 1B (0x01 = data, 0x02 = padding, 0x04 = continuation)
length 2B (полезная нагрузка, ≤1021B)
payload 1021B (данные или random padding до frame_size)
Персональный мессенджер скрывает тайминг: между узлами идёт постоянный поток фреймов. Реальные сообщения Монтаны замещают padding-фреймы, не добавляются к ним. Наблюдатель внутри сети не может отличить перевод от доказательства времени от тишины — всё одинаковые зашифрованные фреймы.
Параметры:
- Baseline frame rate: 1 frame/сек на исходящих соединениях. Входящие — фреймы при наличии данных
- Maximum burst: ≤ 8 frames подряд без паузы ≥ 10ms
- Minimum padding ratio: ≥ 20% фреймов в скользящем окне τ₁ на исходящих
Персональный = доступный: 24 исходящих × 1 frame/сек × 1024 bytes = 24 KB/сек ≈ 60 GB/мес. Приемлемо для домашнего сервера.
Transport Randomness
Все рандомизированные решения транспортного уровня (stem routing, frame scheduling, nonce generation) используют CSPRNG из OS entropy pool. Детерминированный PRNG от node state запрещён для transport-layer randomness.
Transport obfuscation ортогонален консенсусу. TimeChain, state machine работают поверх любого транспорта без изменений.
Выбор пиров
Открытый вход с VDF-барьером делает sybil-узлы дорогими: каждый sybil = τ₂ окон 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) взаимодействуют через свой доверенный узел.
Исходящие соединения
24 исходящих, все полные. 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 из 24 слотов. Eclipse требует узлы в 7+ разных AS в 7+ разных /16 с регистрацией в 7+ разных τ₂.
ASN-карта загружается при запуске. Без карты — fallback на /16.
Адресный менеджер
Две таблицы:
- Новые — адреса полученные через peer exchange и DHT. Узел ещё не подключался
- Проверенные — адреса к которым узел успешно подключался через IBT
Бакетирование: bucket = Hash(secret_key, source_group, addr_group) % N. Детерминированно с секретным ключом — атакующий не может предсказать в какой бакет попадёт его адрес.
Входящие соединения
До 32 входящих. При переполнении — вытеснение:
- Защитить 4 с наименьшим пингом
- Защитить 4 с последними полезными сообщениями (любое валидное сообщение Монтаны которое узел ещё не видел)
- Защитить до 8 из разных подсетей (по одному от каждой)
- Защитить 4 с последними proposals
- Из оставшихся — вытеснить из крупнейшей подсетевой группы
Якоря
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 1952B (ML-DSA-65)
Без node_id и node_pubkey клиент не может вычислить IBT proof для подключения. Peer exchange: не более 100 PeerRecord за сообщение. Не более 1 peer exchange сообщения за τ₁ от каждого peer.
Цензуроустойчивое обнаружение
Генезис: 12 hardcoded bootstrap nodes (IP, node_id, pubkey). Если все 12 IP заблокированы на уровне страны — новый узел не может войти в сеть. Пять независимых каналов обнаружения. Достаточно одного из пяти.
1. Peer exchange. Каждый узел хранит и передаёт список активных пиров новичкам. Достаточно знать IP одного узла — друг, QR-код, мессенджер. Один живой контакт = вход в сеть.
2. DHT. Kademlia DHT поверх libp2p. Узлы находят друг друга без центральной точки. Идентификаторы рандомизированы — DHT не раскрывает node_id до установления соединения Монтаны.
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, 5.
5. Mesh peer exchange. При полном отсутствии доступа к internet (государственный shutdown, отключение межзоновой связности, локальная изоляция) узел обнаруживает локальных peers через mesh transport (Bluetooth LE advertisement, Wi-Fi Direct service discovery). Peer exchange работает на уровне mesh frame с типом frame_type = 0 (discovery) — см. подраздел «Mesh Transport» и «Store-and-Forward Semantics». Физический радиус обнаружения — десятки метров; mesh multi-hop forwarding расширяет эффективный радиус до сотен метров и километров при достаточной плотности устройств. Когда хотя бы одно устройство в mesh-сети получает доступ к internet — вся цепочка синхронизируется через него как через единый шлюз.
Избыточность = устойчивость. Пять каналов независимы по physical-layer доставке (IP internet для 1-4, radio mesh для 5). Блокировка internet-канала на уровне государства не затрагивает канал 5 — отключить mesh требует подавления Bluetooth/Wi-Fi на каждом устройстве физически, что практически нереализуемо.
Dandelion++ (анонимность отправителя)
P2P gossip Монтана ретранслирует операции через все узлы. Без защиты первый пир знает 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 из 24 исходящих как stem_peers (период выбора множества стебельных). Внутри этого окна 693 окон — stem_successor (forward choice одного из 2) ротируется каждое τ₁ — см. Карточку Dandelion++ для нормативной формулировки. Все стебельные операции в эпохе направляются через одного из этих 2 (выбор по hash(msg)).
Применение по типу объекта:
| Объект | Режим | Причина |
|---|---|---|
| UserObject (Transfer Mode A/B, Anchor, ChangeKey, CloseAccount) | 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 окна (выбор из 24 outbound)
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-узел страхует следующий. Таймер τ₁/2 на каждом hop независимо. Если следующий hop уронил сообщение — текущий hop обнаруживает отсутствие операции в gossip и делает fluff сам. Максимальная задержка = τ₁/2 (один hop), не кумулятивная.
Dandelion++ не требует внешней инфраструктуры. Каждый узел Монтаны уже является 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 распределён по 24 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). Ноль новых протокольных примитивов.
Mesh Transport
Internet не всегда доступен. Государственные shutdown (Иран 2019 — неделя, Беларусь 2020 — дни, Мьянма 2021 — месяцы), локальные сбои, изолированные зоны. Монтана поддерживает работу в таких условиях через mesh transport поверх Bluetooth Low Energy и Wi-Fi Direct — устройства обнаруживают друг друга в физическом радиусе и пересылают encrypted сообщения Монтаны hop-by-hop. Mesh не замещает internet transport, а дополняет: при возвращении связности сеть автоматически конвергирует через mesh-internet шлюз.
Mesh transport ортогонален консенсусу так же как internet transport (раздел выше) — state machine работает поверх любого доставочного канала без изменений.
MeshFrame wire format
Все mesh-сообщения фрагментируются на фреймы фиксированного формата:
MeshFrame:
mesh_protocol_version u16 — версия mesh wire format
(0x0001 для v1)
frame_type u8 — 0=discovery, 1=data,
2=ack, 3=forward
ttl u8 — max 16 при создании,
monotonic decrement
на каждом forwarding hop;
ttl=0 → frame дропается
hop_count u8 — 0 при создании,
monotonic increment
на каждом forwarding hop
sender_ref 32B — mesh_session_id инициатора
(не прямой node_id для
privacy на mesh слое)
recipient_hint 32B — encrypted routing hint
либо broadcast marker
(0xFF × 32 = broadcast)
payload_length u16 — длина payload в байтах,
≤ 256
payload variable — encrypted blob,
≤ 256B для fit в один
BLE GATT notification
без fragmentation
mac 16B — HMAC-SHA-256 truncated,
key derived через
HKDF от shared session
secret с domain separator
"mt-mesh-frame-mac"
Итого: 64 + 256 + 16 = 336B максимум
(64 байта header + 256 байт payload + 16 байт MAC)
Инварианты MeshFrame:
mesh_protocol_version∈ {0x0001} для v1; иные значения rejectframe_type∈ {0, 1, 2, 3}; иное → dropttl∈ [0, 16]; при создании фрейма sender устанавливает ≤ 16; при каждом forwardttl := ttl - 1; еслиttl = 0и frame требует forwarding — drophop_count∈ [0, 16]; при создании = 0; при каждом forwardhop_count := hop_count + 1; еслиhop_count > 16→ drop (защита от malformed increment)sender_ref= 32 байта = mesh_session_id отправителя (см. derivation ниже), не прямой node_idrecipient_hint= 32 байта; значение0xFF × 32обозначает broadcast, иное — encrypted routing hint; получатель проверяет соответствие self через локальное statepayload_length≤ 256; строгое неравенство иначе → droppayloadдлина точноpayload_lengthбайт; encrypted blob (шифрование выполнено на уровне session, mesh transport layer видит только ciphertext)mac= 16 байт, HMAC-SHA-256(session_mac_key, header_bytes || payload) truncated до первых 16 байт; session_mac_key = HKDF-SHA-256(session_shared_secret, salt=empty, info="mt-mesh-frame-mac", length=32); mismatch MAC → drop + increment soft-blacklist counter для sender_ref- Signature verify rule: MeshFrame не подписывается ML-DSA-65 напрямую (MAC достаточен для integrity между двумя peer в установленной session); identity-level authentication выполняется один раз при mesh IBT handshake, subsequent frames authenticated через session MAC
- Cross-field consistency:
hop_count + ttl ≤ 16в любом состоянии (initial: hop_count=0, ttl≤16; при каждом forwardttl := ttl - 1,hop_count := hop_count + 1, сумма инвариантна); нарушениеhop_count + ttl > 16— malformed frame, drop + increment soft-blacklist counter для peer из которого пришла frame
mesh_session_id derivation. Для каждой mesh сессии (между парой peers после mesh IBT handshake) выводится:
mesh_session_id = HKDF-SHA-256(
ikm = shared_secret_from_noise_handshake,
salt = mesh_session_nonce_initiator || mesh_session_nonce_responder,
info = "mt-mesh-session",
length = 32
)
mesh_session_id используется в поле sender_ref вместо прямого node_id — mesh transport на уровне wire format не раскрывает identity отправителя случайному слушателю в радиусе. Identity раскрывается только peer с которым установлена сессия (они знают mesh_session_id).
Валидация MeshFrame.
mesh_protocol_versionсовпадает с ожидаемой версией peer. Mismatch → drop, no forward.frame_type ∈ {0, 1, 2, 3}. Иное → drop.ttl ∈ [0, 16]. Если ttl=0 и frame пришёл для forwarding — drop.hop_count ≤ 16. Иное → drop (защита от malformed increment).payload_length ≤ 256. Иное → drop.macverify через HMAC-SHA-256 с session key. Mismatch → drop, increment soft-blacklist counter sender_ref.- Для
frame_type = 3 (forward)— применить правила Store-and-Forward Semantics (ниже).
Mesh framing profile
Internet transport uniform framing (подраздел «Uniform Framing») не применяется к mesh transport. Mesh имеет независимый framing profile:
Internet (существующий):
frame_size = 1024 bytes
baseline_rate = 1 frame/сек
контекст = TLS 1.3 over IP
Mesh (v1):
frame_size = 256 bytes (fit в BLE MTU типично
без application-level fragmentation
в большинстве стеков iOS/Android)
baseline_rate = 1 frame/10 сек (baseline advertisement
+ occasional data, battery-sustainable)
burst_mode_rate = 1 frame/сек (активируется ТОЛЬКО при
активной mesh chat session, не continuous)
burst_mode_duration = ≤ 120 сек после последнего data frame,
затем возврат к baseline_rate
fragmentation = sequence numbers для сообщений > 256B,
reassembly на получателе через seq_id
в payload header уровня application
Обоснование параметров:
- 256B — BLE MTU реально варьируется 23-512B, большинство современных iOS/Android поддерживают ≥ 247B, 256B выбран как compromise fit-without-fragmentation на mainstream устройствах
- 1 frame/10 сек baseline — continuous Bluetooth scanning при более частом ритме съедает 30-50% батареи смартфона за несколько часов; 1/10s профиль extends battery usability до рабочего дня
- burst до 1/сек — активная переписка требует reasonable responsiveness; активация по событию «активный chat session» ограничивает всплеск энергопотребления ко времени реального использования
Fragmentation
Сообщения превышающие 256B fragmented на уровне application перед enqueue в mesh:
ApplicationPayload (до fragmentation):
fragment_count u16 — общее число фрагментов
fragment_index u16 — index текущего фрагмента (0-based)
message_id 32B — unique id сообщения,
shared across всех фрагментов
data variable — часть encrypted payload
Получатель собирает фрагменты по message_id, порядок восстанавливается через fragment_index. Timeout reassembly: τ₁ от первого полученного фрагмента (по локальному кварцу транспортного слоя, outside [I-18] scope) — если не все собраны, partial drop. Fragment_index ≤ 255 (max 256 фрагментов × 256B payload = 64KB верхняя граница одного application message; большие объёмы — через Content Layer chunking на blob уровне).
Mesh discovery flow
- Устройство в mesh-активном режиме периодически (baseline_rate = 1 frame/10 сек) бродкастит
frame_type = 0 (discovery)сsender_ref = mesh_session_id_self_generatedиpayload= short advertisement: protocol version, capability flags, optional trust hint. - Другие устройства в радиусе принимают broadcast, извлекают advertisement.
- Если принимающее устройство считает инициатора потенциально интересным (известный контакт в адресной книге; broadcast addressed to broadcast marker и устройство в broadcast-listening mode; любое другое правило application) — оно инициирует mesh IBT handshake (см. «Identity-Bound Tunnel» выше, формула
mesh_proof). - После успешного handshake — session установлена, оба peer добавляют
mesh_session_idв active sessions. - Обмен данных происходит через
frame_type = 1 (data).
Battery management
Reference implementation рекомендуется:
- Scheduled Bluetooth scan: 1 раз в 10 секунд при baseline, чаще при burst
- Wi-Fi Direct используется только для high-throughput сессий (передача больших файлов), не continuous
- iOS background mode constraints: полный mesh transport работает только в foreground; в background доступно ограниченное Core Bluetooth BGTaskScheduler сканирование
- Android: BLE advertisement и scanning в background — стандарт платформы, требует declared foreground service notification для compliance
Store-and-Forward Semantics
Mesh transport inherently async: получатель сообщения может быть вне радиуса в момент отправки. Store-and-forward semantics описывают как промежуточные устройства буферизуют и пересылают сообщения к их конечному получателю.
Buffer model
Каждое устройство в mesh-активном режиме поддерживает локальный buffer:
MeshBuffer (локальный state устройства):
entries: map<frame_hash, BufferEntry>
BufferEntry:
frame MeshFrame
receipt_seq u64 (локальный sequence counter, инкрементируется
при каждом receive; используется для local FIFO
ordering в buffer; не передаётся в сеть)
ttl_remaining u8 (decremented каждый forwarding hop)
sender_ref 32B (из frame, для per-sender quota)
forwarded_to set<peer_id> (peers которым уже переслано,
защита от петель)
frame_hash = SHA-256(MeshFrame serialized) — ключ для идемпотентного recept.
Buffer policies
Capacity limits (по умолчанию, настраиваемо в реализации):
- Max buffer size per device: 1024 frames (≈ 336 KB)
- Max retention per frame: 1440 τ₁ (TTL expiry на buffer entry, эмерджентно ≈ 1 сутки на genesis-калибровке; независимо от
ttlв frame который decremented per hop) - Max frames per sender_ref in buffer: 10 concurrent
Priority queue (при enqueue):
- Own sent frames (frames originated by this device) — highest priority
- Frames addressed to known contacts (locally stored) — high priority
- Frames addressed to unknown recipients (broadcast или unknown recipient_hint) — low priority
Drop policy при overflow:
- Первое при переполнении — drop low-priority oldest
- При исчерпании low-priority — drop high-priority oldest (не own)
- Own frames не дропаются до expiry
Per-sender quota
Защита от flood DOS (вектор M1 из adversarial review):
Rate limits per sender_ref:
max_frames_per_τ₁ = 10
max_frames_in_buffer = 10 concurrently
При превышении:
- Новые frames от этого sender_ref дропаются
- Sender_ref получает signed rate-limit ack с отказом
- Soft-blacklist local: exponential backoff в τ₁,
первое нарушение — 1 τ₁ ignore, второе — 2 τ₁,
и т.д. до 60 τ₁ максимум
Signed rate-limit acks
Relay подписывает acknowledgement для каждой принятой (и forwarded или сохранённой) frame:
MeshAck:
acked_frame_hash 32B — SHA-256 frame которая acked
relay_node_id 32B
status u8 (0=accepted, 1=buffered,
2=forwarded, 3=rejected_quota,
4=rejected_expired)
ack_seq u64 — relay-локальный монотонно
возрастающий sequence counter
ack-ов; не передаёт время,
только порядок выпуска ack-ов
у конкретного relay
signature 3309B — ML-DSA-65_sign(
relay_privkey,
"mt-mesh-ack"
|| acked_frame_hash
|| relay_node_id
|| status
|| ack_seq)
Инварианты MeshAck:
acked_frame_hash= SHA-256 over canonical serialization MeshFrame к которому относится ack; receiver ack'а проверяет что хэш соответствует реально отправленной framerelay_node_id= SHA-256("mt-node" || relay_pubkey); receiver должен знать relay_pubkey для проверки подписиstatus ∈ {0, 1, 2, 3, 4}; значение вне диапазона → reject ack как malformedack_seq— relay-локальный u64 sequence counter; инкрементируется на 1 при выпуске каждого ack данным relay; используется только для local ordering ack-ов на стороне получателя; не имеет временной семантики (не передаёт ни wall-clock, ни длительность); не consensus-critical, не участвует в state transitionssignature= 3309 байт ML-DSA-65, валидация черезrelay_pubkey; подписываемое сообщение канонически сериализовано в порядке перечисления полей (acked_frame_hash || relay_node_id || status || ack_seq)- Signature verify rule: ML-DSA-65.verify(relay_pubkey, domain_separator || canonical_payload, signature) = valid; иначе drop ack
- Ack не применяется к state transitions — это чисто local signal для sender rate adjustment, вне scope consensus
Sender использует ack для:
- Confirmation что frame принята (status ∈ {0, 1, 2})
- Detection перегрузки (status=3 → flood suppression, уменьшить rate)
- Detection expired frames (status=4 → frame outdated, не повторять)
Отсутствие ack в пределах τ₁/2 после отправки → sender предполагает relay недоступен, пробует другой peer.
Forwarding algorithm
on_receive(frame, from_peer):
frame_hash = SHA-256(frame)
if frame_hash in buffer:
return # дубликат, already processed
if not validate_frame(frame):
drop; increment soft-blacklist counter from_peer
return
if frame.sender_ref in soft_blacklist:
drop silently
return
if buffer.sender_count(frame.sender_ref) >= 10:
send_ack(frame, status=3) # rejected_quota
return
if frame.recipient_hint matches self:
deliver_to_application(frame)
send_ack(frame, status=0)
return
if frame.ttl == 0:
drop; send_ack(frame, status=4)
return
# forward case
frame.ttl -= 1
frame.hop_count += 1
buffer.add(frame)
send_ack(from_peer, frame, status=1) # buffered
# opportunistic forwarding
for peer in active_mesh_peers:
if peer not in frame.forwarded_to and
peer != from_peer and
peer accepts forwarding:
send(peer, frame)
frame.forwarded_to.add(peer)
send_ack(from_peer, frame, status=2) # forwarded
on_timer_expired(entry):
# local buffer expiry, independent от frame.ttl
buffer.remove(entry)
Interaction с internet
Когда устройство получает internet connectivity, оно опционально (по настройке пользователя) пересылает buffered mesh frames в internet-сеть:
- Для каждой frame в buffer с
recipient_hintкоторый можно разрешить в account_id - Пересылка через обычный P2P gossip к Account Host получателя
- После успешного acknowledgement с internet-стороны — frame удаляется из mesh buffer
- Internet-to-mesh обратное направление аналогично: устройство с internet получает сообщение для offline-получателя, enqueues в mesh buffer для forwarding через ближайшие peers
Это делает internet-connected устройство gateway между internet-сетью и изолированной mesh-областью. Один такой шлюз восстанавливает связность для всего mesh-кластера до внешнего мира.
Privacy Scope (точная зона ответственности)
Прежде чем описать Семь слоёв сетевой защиты, фиксируем точные границы того что Montana защищает на сетевом уровне и что намеренно не закрывается.
Three-level decomposition
Privacy в Montana работает на трёх отдельных уровнях, каждый со своими гарантиями:
-
Wire-level (transport layer): что видит провайдер / DPI / наблюдатель отдельного линка.
- Защита: TLS 1.3 + Noise + IBT (ML-DSA-65 PQ peer auth) + Uniform Framing + Transport Randomness + Dandelion++ + Label Rotation per τ₁ + Censorship-resistant discovery
- Закрывает: local DPI, ISP, regulator с перехватом одного линка, small-medium Sybil eclipse, long-term recipient linkability через провайдеров приложений
- НЕ закрывает: global passive adversary с GPS-precision timing-correlation на ВСЕХ backbone links одновременно (open research problem всей anon-net области)
-
Content-level (application data): что видит хостящий узел или наблюдатель proposal-broadcast.
- Защита: Anchor + ML-KEM-768 encryption (data_hash в proposal, content off-chain encrypted под recipient ключ) + Double Ratchet PQ для messenger end-to-end + PQXDH async handshake
- Закрывает: content surveillance со стороны хоста, recipient identity через ephemeral labels
- НЕ закрывает: endpoint compromise (RAT/spyware) — out of scope любого network protocol
-
Financial-level: что видит любой наблюдатель cemented proposal.
- Status: ОТКРЫТ per [I-2] — балансы, sender_account_id, recipient, amount публичны.
- Это intentional design feature для регуляторной совместимости (FATF/MiCA), аудитируемости и [I-3] детерминизма consensus state.
- Privacy финансовых движений на protocol level намеренно не предоставляется.
Privacy Tier model для пользователей
Пользователь выбирает уровень privacy по trade-off против latency и bandwidth:
| Tier | Stack | Latency | Bandwidth | Threat closure |
|---|---|---|---|---|
| 1 default | Семь слоёв baseline (TLS+IBT+Dandelion+Label Rotation+Mesh) | <500мс | minimal | Local DPI, ISP, regulator (один линк), small-medium Sybil, long-term recipient unlinkability |
| 2 recommended | + own узел (Light-Node-at-Home) + Tor entry + Noise_PQ handshake | 500мс — 2с | medium | + ISP не видит «Montana traffic», + bypass legal request, + quantum store-now-decrypt-later |
| 3 paranoid financial | + canonical Mempool buffering + end-of-window batch flush + cover traffic 100% | 60-120с | full | + temporal unlinkability sender's local act → operation appearance в state |
| 4 research-grade | + artificial random delay 5-30 мин + multiple onion paths | 5-30 мин | full | + extreme protection from mass-surveillance flowtracking; practically maximum при non-information-theoretic anonymity |
Tier 1 — автоматически для всех пользователей. Tier 2-4 — opt-in.
Canonical-aggregation closure для timing-correlation (unique Montana property)
Montana отличается от Tor / Loopix / I2P fundamentally в том как обрабатываются operations на сетевом уровне:
Tor / Loopix / I2P model:
packet_α emit immediately → traverse network → arrive at recipient
Adversary observes individual packet timing → correlates Alice IP ↔ Bob IP
Deanonymization после 100-1000 messages
Montana model:
Alice creates operation_α локально в момент T_local
→ Mempool buffer на узле-операторе (random hold N окон)
→ Dandelion++ stem 2-hop форвардинг
→ Operator's mempool → operator selection lottery
→ Aggregation: proposal_W = canonical(op_α, op_β, ..., op_ω)
включает 100-10000 operations from different accounts
→ Broadcast aggregate
Adversary observes aggregate proposal, individual op_α неотличим от op_β
Deanonymization требует 10⁶-10⁸ messages (orders of magnitude harder)
Уникальные primitives Montana которые работают вместе для этого свойства:
- Mempool temporal buffering — Alice's individual emit timing decoupled от operation appearance в state
- Canonical proposal aggregation — proposal содержит operations от множества accounts, individual flow смешан
- VDF-canonical aggregation point — все proposals публикуются в canonical моменты (end-of-window) — гомогенный stream events для adversary
- Block Lattice independent AccountChain — каждый аккаунт пишет в свою цепочку, structurally separate но bundled в proposal
- Dandelion++ stem buffering — operator entry скрыт через 2-hop stem propagation
Operations в Montana — это state events на canonical TimeChain, не ephemeral network messages. Этой fundamental architectural property нет ни в Tor (per-message routing), ни в Loopix (per-message Poisson mixing), ни в I2P (per-tunnel routing). Это даёт Montana уникально сильное ослабление global passive timing-correlation — не absolute closure (open research problem остаётся), но на порядки сильнее existing systems.
Honest claim — что закрывается и что не закрывается
| Adversary class | Tier 1 | Tier 2 | Tier 3 | Tier 4 |
|---|---|---|---|---|
| Local DPI / ISP | ✅ через TLS+IBT | ✅ через Tor | ✅ | ✅ |
| Government legal request to ISP | ⚠️ partial — DPI закрыт, IP виден | ✅ через Tor | ✅ | ✅ |
| Active probing | ✅ через IBT | ✅ | ✅ | ✅ |
| Sybil eclipse | ✅ через 4-dim diversity | ✅ | ✅ | ✅ |
| Sender authorship inference (ближайшие peers) | ✅ через Dandelion++ | ✅ | ✅ | ✅ |
| Long-term recipient linkability | ✅ через Label Rotation per τ₁ | ✅ | ✅ | ✅ |
| Hosting third-party metadata | ⚠️ visible to host | ✅ через own node | ✅ | ✅ |
| Content surveillance | ✅ через Anchor encryption | ✅ | ✅ | ✅ |
| Quantum store-now-decrypt-later | ❌ TLS handshake X25519 vulnerable | ✅ через Noise_PQ | ✅ | ✅ |
| Backbone GPS-precision timing-correlation | ⚠️ partial through aggregation (10⁶ msg threshold) | ⚠️ same + Tor obscures | ⚠️ + temporal randomization | ⚠️ + multi-path delays |
| Endpoint compromise (RAT) | ❌ out of scope | ❌ out of scope; mitigation через Light-Node-at-Home damage containment | ❌ | ❌ |
| Financial state visibility | ❌ public per [I-2] by design | ❌ same | ❌ same | ❌ same |
Маркеры: ✅ closed; ⚠️ partial / mitigated; ❌ not closed (intentional или fundamental limit).
Endpoint compromise — Montana damage containment (architectural mitigation)
Network protocol не может prevent endpoint compromise. Но Montana архитектурно ограничивает damage через unique patterns:
- Light-Node-at-Home split (App spec § 26): master_seed на home node, phone имеет только ephemeral session keys. Compromise phone ≠ compromise master key.
- VDF-anchored ephemeral session rotation per τ₁: session key derivable через
HKDF(master_seed, current_window || "session-W"). Maximum exposure window = 60 sec. - Junona local pre-processing: AI агент на own node делает decryption + summarization; phone никогда не имеет full content в memory.
- Block Lattice sub-account hierarchy: phone использует daily-spend sub-account ($X/day limit); master savings account только на home node.
- Hardware-backed enclave integration: master_seed в iOS Secure Enclave / Android StrongBox.
Сравнение с existing messengers:
| System | Endpoint compromise impact |
|---|---|
| Signal | Compromise device = full chat history forever (single trust domain) |
| Compromise device = full history + cloud sync | |
| Telegram | Compromise device = full history + cloud + saved messages |
| Montana с Light-Node-at-Home | Compromise phone = max loss sub_account_limit × 60_sec_window_content (multi-domain trust) |
Что не покрывается ни одним tier
Два fundamental open problems которые не закрывает никто (включая Tor, Loopix, I2P):
-
Global passive adversary с GPS-precision timing-correlation на всех backbone links одновременно. Montana уникально ослабляет через canonical aggregation (10⁶-10⁸ message threshold вместо 10²-10³ как в Tor), но не закрывает абсолютно — это open research problem с 1980-х в anon-net области.
-
Endpoint compromise через RAT / hardware-level malware. Network protocol бесполезен — данные читаются до encryption. Montana архитектурно ограничивает damage через trust domain split, но не prevents compromise. Полная защита требует hardware secure enclave + verified boot + careful endpoint hygiene.
Эти ограничения honestly зафиксированы в spec — пользователь знает scope защиты до использования. Marketing-claim «полная анонимность» отвергается как overpromise который рухнёт при первом серьёзном аудите.
Семь слоёв — одна конструкция
Слой 1: Transport Obfuscation персональный сервер скрывает содержимое и тайминг
Слой 2: Peer Selection start_window + network diversity constraints
Слой 3: NAT Traversal каждый может войти, даже за NAT
Слой 4: Censorship-Resistant Discovery пять каналов, достаточно одного
Слой 5: Dandelion++ пиры не знают кто автор операции
Слой 6: Mesh Transport работа при отключении internet,
hop-by-hop Bluetooth / Wi-Fi Direct
Слой 7: Store-and-Forward Semantics ephemeral буферизация в mesh,
per-sender quota, signed acks
Каждый слой закрывает свой вектор. Ни один не требует внешней инфраструктуры. Всё построено поверх libp2p (для internet-слоёв 1-5) и нативных BLE/Wi-Fi Direct API (для mesh-слоёв 6-7) плюс существующего gossip. Сетевой уровень ортогонален консенсусу — ни один state transition не затронут.
Protocol Message Layer
Внутри IBT uniform frames протокольные сообщения следуют общему envelope format. Эта секция нормативно определяет wire format всех сообщений Монтаны для cross-implementation совместимости.
Envelope format.
ProtocolMessage:
msg_type 1B <- u8, код типа сообщения
msg_version 1B <- u8, версия формата сообщения (= 1 для v28.x)
request_id 8B <- u64 little-endian, correlation id для request/response (= 0 для one-way gossip)
payload_length 4B <- u32 little-endian, размер payload в байтах
payload ?B <- payload_length байт, формат определяется msg_type
Envelope всегда 14 байт header + payload. Поскольку IBT uniform frames имеют payload 1021B, ProtocolMessage может занимать один или несколько фреймов через flag 0x04 continuation (см. Uniform Framing).
Реестр типов сообщений.
| Код | Тип | Направление | Payload |
|---|---|---|---|
| 0x01 | Transfer | one-way gossip | Transfer объект (Mode A или Mode B; serialize по canonical encoding; режим определяется длиной payload и наличием receiver в Account Table) |
| 0x02 | reserved | — | Освобождён (ранее выделен под отдельную gossip-категорию активации; gossip envelope namespace независим от operation type-byte). Не выделять вновь. |
| 0x03 | ChangeKey | one-way gossip | ChangeKey объект |
| 0x04 | Anchor | one-way gossip | Anchor объект |
| 0x10 | NodeRegistration | one-way gossip | NodeRegistration объект |
| 0x20 | BundledConfirmation | one-way gossip | BundledConfirmation объект |
| 0x21 | VDF_Reveal | one-way gossip | VDF_Reveal объект |
| 0x22 | Proposal | one-way gossip | Proposal объект |
| 0x40 | FastSyncRequest | request | {anchor_window: u64, resume_offset: u64} |
| 0x41 | FastSyncResponse | response | chunked snapshot data (см. ниже) |
| 0x42 | FastSyncError | response | {code: u8, message: bytes[≤255]} |
| 0x50 | PeerListRequest | request | {max_count: u16} |
| 0x51 | PeerListResponse | response | {count: u16, peers: count × PeerEntry} |
| 0x60 | BatchLookupRequest | request | {query_type: u8, count: u8, queries: count × query_entry} (см. раздел «Batch Lookup Protocol») |
| 0x61 | BatchLookupResponse | response | {query_type: u8, count: u8, results: count × result_entry} |
| 0x62 | BatchLookupError | response | {query_type: u8, error_code: u8} |
| 0x63 | RangeSubscribeRequest | request | {count: u16, labels: count × 32B} (см. раздел «Label Rotation + Range Subscribe Protocol») |
| 0x64 | RangeSubscribeResponse | response | {blob_count: u16, blobs: blob_count × BlobEntry} |
| 0x65 | RangeSubscribeError | response | {error_code: u8} |
| 0xF0 | Ping | request | (no payload) |
| 0xF1 | Pong | response | (no payload) |
| 0xFF | Bye | one-way | {reason: u8} (graceful shutdown) |
Message versioning: msg_version = 1 для всех v28.x. Изменение wire format = increment msg_version, требует protocol version upgrade.
Unknown msg_type → получатель логирует и игнорирует (forward compatibility). Unknown msg_version → получатель отвечает FastSyncError с кодом unsupported_version и разрывает соединение.
Structured payloads.
PeerEntry:
PeerEntry:
ip_version 1B <- u8, 0x04 или 0x06
ip 16B <- IPv4 в последних 4 байтах (первые 12 = 0x00) или IPv6 полностью
port 2B <- u16 little-endian
node_id 32B
start_window 8B <- u64 little-endian, из Node Table
= 59 bytes fixed
FastSyncResponse chunked delivery:
FastSyncResponse chunk:
chunk_index 4B <- u32 little-endian, начинается с 0
total_chunks 4B <- u32 little-endian, общее число chunks для текущего запроса
table_id 1B <- u8: 0x01 Account, 0x02 Node, 0x03 Candidate, 0x04 Proposals
record_count 4B <- u32 little-endian, записей в этом chunk
records ? <- record_count × serialize(record) по canonical encoding
Response состоит из N chunks (с одним request_id). Получатель собирает по chunk_index. После получения всех total_chunks — reconstructs Merkle root и проверяет против proposal_W.
Connection lifecycle.
Порядок установки соединения:
1. TCP SYN / SYN-ACK / ACK (standard)
2. TLS 1.3 handshake (server certificate optional)
3. Noise key agreement внутри TLS (mutual pubkey authentication)
4. IBT proof exchange (клиент отправляет ML-DSA-65 signature)
5. Access level determination (node / candidate / account, см. Transport Obfuscation)
6. Готово к обмену ProtocolMessages
Timeouts установки (по локальному кварцу транспортного стека, outside [I-18] scope; emergent значения при genesis-калибровке):
- TCP connect: τ₁/2
- TLS handshake: τ₁/6
- Noise + IBT: τ₁/6
- Всё вместе не более 1 τ₁ до готовности
Если любой шаг превысил timeout → разрыв, retry с другим пиром.
Keepalive.
- Ping раз в τ₁ на idle соединении (нет данных)
- Pong должен прийти до завершения текущего τ₁ у получателя Pong
- Три подряд τ₁ без полученного Pong → disconnect
- При активном обмене данными Ping не обязателен (реальные данные = evidence активности)
Ping/Pong не несут payload — это чистая liveness-проверка. Любая локальная RTT-оценка отправителем — concern транспортного слоя его ОС (CLOCK_MONOTONIC kernel-level, outside scope [I-18]) и не передаётся в подписанных объектах.
Graceful shutdown.
Инициатор: отправляет Bye с reason code:
0x00 — normal shutdown
0x01 — going offline for maintenance
0x02 — peer list refresh (попытка найти лучших пиров)
0x03 — resource limits (слишком много соединений)
0x04 — protocol violation (валидация failed много раз)
0x05 — version mismatch
Получатель acknowledges через свой Bye, затем TLS close_notify, затем TCP FIN. Максимум τ₁/12 на graceful shutdown (по локальному кварцу транспортного стека, outside [I-18] scope), иначе forced close.
Peer discovery algorithm.
Новый узел при старте:
1. Извлечь bootstrap peers из Genesis Decree (захардкожено)
2. Выбрать 1-3 random bootstrap peer, connect (с PoW для bootstrap per Transport Obfuscation)
3. Выполнить IBT (account keypair для первого подключения нового узла)
4. Отправить PeerListRequest с max_count = 128
5. Получить PeerListResponse с до 128 известных peer-ов
6. Применить diversity constraints (/16, ASN, start_window) к полученному списку
7. Выбрать 24 outbound candidates по diversity
8. Параллельно connect к выбранным
9. После успешного IBT с реальным peer — disconnect от bootstrap (освобождая bootstrap slots)
10. Maintaining: PeerListRequest каждые ~τ₂ окон для обновления таблицы "проверенных" peers
Bootstrap exceptional:
- PoW при подключении (target ~100ms CPU per Transport Obfuscation)
- Ограничение: не более 3 одновременных bootstrap подключений на узел
- Освобождается после 13 реальных peers connected
Peer exchange
Между двумя подключёнными узлами:
Каждые τ₂_windows:
A → B: PeerListRequest {max_count: 64}
B → A: PeerListResponse {peers[]}
Узел поддерживает две таблицы:
- Новые peers: недавно узнанные (от bootstrap или PeerListResponse), ещё не использованные
- Проверенные peers: те с которыми были успешные соединения в прошлом
При выборе outbound: 50/50 случайно из обеих таблиц. Bucket по секретному ключу узла предотвращает external enumeration.
Retry policy.
- Failed connect: exponential backoff в локальных кварцевых секундах транспортного стека (1s, 2s, 4s, 8s, ..., max 5τ₁; outside [I-18] scope)
- Peer rejected через IBT fail: peer помечается bad на 1τ₁
- Peer disconnected с reason 0x04 (protocol violation): peer blacklisted на 24τ₁
- Bootstrap PoW retry: no backoff (PoW сам служит rate limit)
Error codes для FastSyncError:
0x01 snapshot_unavailable -- запрошенный anchor_window слишком старый (peer не хранит)
0x02 snapshot_too_large -- snapshot больше чем peer готов отправить
0x03 unsupported_version -- msg_version не поддерживается
0x04 resource_exhausted -- peer перегружен
0x05 access_denied -- peer не отдаёт Fast Sync клиентам (только nodes)
Сеть vs консенсус — граница.
Network layer параметры (timeouts, retry delays, keepalive intervals) — implementation guidance, могут варьироваться между реализациями без consensus impact. Значения в этой секции — рекомендуемые defaults. Consensus-critical: wire format (envelope, payloads), IBT proof format, Bootstrap PoW formula, message type codes. Изменение consensus-critical параметров требует protocol version upgrade.
Batch Lookup Protocol
Протокол обеспечивает baseline приватность lookup-запросов для account-only пользователей (тех, кто работает через чужой узел без собственной инфраструктуры). Когда клиент запрашивает информацию об аккаунтах (связка предварительных ключей, проверка существования), запрос группируется в batch из K элементов, среди которых ровно один — реальная цель, остальные — случайные decoy-аккаунты. Хост видит K-элементный запрос, но не знает какая из позиций real.
Механизм применяется только для cold-path lookups. Hot-path — уже известные контакты пользователя — разрешается локально на клиенте без обращения к сети (см. App spec раздел «Модуль обнаружения контактов»).
Константы
Определены в ProtocolParams Genesis Decree:
batch_lookup_k = 16— обязательный размер batch. Отклонения запрещены (детализация: см. обоснование в разделе «Обоснование протокольных констант»).max_batch_lookups_per_τ₁ = 16— rate limit на один account per окно τ₁, защита от DoS на хоста.
Message type 0x60 — BatchLookupRequest
Payload format:
BatchLookupRequest:
query_type 1B <- u8: 0x01 pre_key_bundle, 0x03 account_exists
count 1B <- u8, обязательно == batch_lookup_k (= 16)
queries count × query_entry (тип query_entry зависит от query_type)
где query_entry:
query_type == 0x01 (pre_key_bundle): 32B account_id
query_type == 0x03 (account_exists): 32B account_id
Клиент формирует batch: один real target + 15 decoy-аккаунтов, перемешанных в произвольном порядке. Клиент локально запоминает позицию real target внутри batch.
Инварианты BatchLookupRequest:
query_type ∈ {0x01, 0x03}; иное → rejectUnsupportedType(error_code 0x02)count == batch_lookup_k(строгое равенство, = 16); иное → rejectInvalidCount(error_code 0x03)- Размер
queries[]точноcount × entry_size(query_type)байт - Source account (IBT-authenticated sender) активен в Account Table;
max_batch_lookups_per_τ₁не превышен за текущее окно - При превышении rate limit → reject
RateLimited(error_code 0x01)
Message type 0x61 — BatchLookupResponse
Payload format:
BatchLookupResponse:
query_type 1B
count 1B <- = count из request (16)
results count × result_entry (в том же порядке, что и queries)
где result_entry:
query_type == 0x01 (pre_key_bundle): 4B length prefix + variable ML-KEM-768 bundle
(length=0 → bundle отсутствует / never published)
query_type == 0x03 (account_exists): 1B (0x00 → not found, 0x01 → exists)
Хост обязан обработать все count queries и вернуть count results в том же порядке. Частичные ответы запрещены — либо полный BatchLookupResponse, либо BatchLookupError.
Message type 0x62 — BatchLookupError
BatchLookupError:
query_type 1B
error_code 1B <- 0x01 RateLimited, 0x02 UnsupportedType, 0x03 InvalidCount
Validation workflow хоста
- Проверить IBT-аутентификация клиента (уровень 3 accepted для account-only пользователей)
- Проверить structural инварианты BatchLookupRequest
- Проверить rate limit для client account
- Выполнить
countlookups против локального state (Account Table, cemented Anchor archive) - Собрать
countresults в том же порядке что queries - Отправить BatchLookupResponse
Хост не логирует individual queries для privacy hygiene — только aggregate rate counters per-account для enforcement лимита.
Effective privacy analysis
На масштабе сети 1B+ активных пользователей клиент собирает passively-observed pool активных аккаунтов через gossip proposals. Realistic pool size: 10K–100K накопленных за τ₂ observation window.
При pool size 10K–100K и K=16:
- Effective anonymity: ~2–3 бита (1-in-4 до 1-in-8 practical protection)
- Intersection attack resistance: intersection attack требует ~1000+ batches observation (~десятилетия активности) — практически нерелизуема
- Semantic filtering: клиент обязан использовать per-function dummy pools (pre-key bundles только от accounts published bundle, и т.д.) — детализация в App-спеке
Это partial protection, не абсолютная. Полное закрытие lookup-поверхности — через собственный узел (Light-Node-at-Home в App-спеке). Протокол делает максимум возможного при ограничениях [I-5] (commodity hardware, без PIR), [I-6] (без privacy mixers) и [I-7] (минимальная крипто-поверхность).
Rate limit rationale
max_batch_lookups_per_τ₁ = 16 при K=16 даёт максимум 256 queries per аккаунт per окно τ₁. Типичная активность пользователя мессенджера: ≤ 50 queries per sessions, несколько sessions per day. Лимит покрывает reasonable usage и защищает хоста от DoS amplification.
При превышении лимита клиент получает RateLimited error и обязан применить exponential backoff до следующего окна τ₁.
Применимость инвариантов
- [I-5] Commodity hardware: ноль тяжёлых крипто операций, только SHA-256 compare для lookups — стандартный read. Работает на любом commodity узле.
- [I-6] Регуляторная совместимость: plaintext batch lookup = bulk read operation, не privacy mixer, не ring signature, не stealth address, не hidden flow. Host видит все K queries явно.
- [I-7] Минимальная крипто-поверхность: ноль новых крипто примитивов.
- [I-15] Time-based scarcity: rate limiting через
max_batch_lookups_per_τ₁— time-based защита, соответствует [I-15]. - [I-16] Out-of-band identity binding: batch lookup предшествует первому сообщению; client получает pre-key bundle, вычисляет отпечаток, показывает пользователю для out-of-band сверки. Совместимо с [I-16] по конструкции.
Label Rotation + Range Subscribe Protocol
Протокол baseline приватности для Blob Buffer polling пользователями account-only (тех кто работает через чужой узел). Защищает от long-term session identification через статические queue labels. Включает механизм catch-up для пользователей, возвращающихся онлайн после периода offline.
Механизм применяется к клиентскому слою (messenger sessions). Rotation формулы — authoritative в App-спеке раздел 23.2 (single source of truth). Catch-up protocol (RangeSubscribe) — protocol-level message types.
Что закрывается и что остаётся открытым
Closed через rotation:
- Long-term session identification. Хост не может построить stable map
account_X → {sessions_X}потому что queue labels меняются каждый τ₁. Набор наблюдаемых labels за разные окна нельзя correlate без знанияinitial_root_keyсессии. - Historical reconstruction через архивные логи хоста. Даже сохранённые label наблюдения нельзя decompose в session identity без session keys.
Permanent architectural limits (не закрываются на protocol level для account-only):
- Session count. Хост видит количество активных label subscriptions per τ₁ как proxy для числа активных сессий. Сокрытие требует cover traffic, которая при self-cover отличима от real по provenance (blob arriving from client's own IBT vs external gossip). Protocol-level ambient cover требует продолжительной фоновой генерации фиктивных сообщений и не scales на 1B. Архитектурно непреодолимо в рамках инвариантов Монтаны.
- Activity timing patterns. Хост видит когда клиент публикует и получает сообщения. Защита требует constant-rate cover — те же ограничения что session count.
- Cross-host collusion per-τ₁. Если хост Alice и хост Bob координируются — pair identification возможна за один τ₁ (publish-receive correlation). Rotation защищает от long-term накопления, не от per-τ₁ collusion.
Полная защита от этих трёх классов — только Light-Node-at-Home (см. App-спека раздел 26). Свой узел = no third-party observer = эти leaks не существуют для данного пользователя.
Label rotation formula
Queue labels для session ротируются детерминистически каждый τ₁ на основе текущего window_index. Authoritative формула — в App spec раздел 23.2.
Краткое описание: label derivation использует HKDF-SHA-256 с initial_root_key сессии как IKM, session_id как salt, и "mt-queue-rotation" || direction_byte || W.to_le_bytes_8 как info. Клиенты обеих сторон session детерминистически выводят одинаковый label для одинакового окна.
Sync tolerance: получатель подписан на labels для W ∈ {W_current, W_current − 1} — двухоконная tolerance к рассинхронизации канонических окон между участниками.
Message type 0x63 — RangeSubscribeRequest
Для пользователей, возвращающихся онлайн после периода offline. Клиент вычисляет labels локально для нужного диапазона windows и запрашивает blobs от хоста.
Payload format:
RangeSubscribeRequest:
count 2B <- u16 LE, число labels в запросе (≤ max_range_labels_per_request = 10 000)
labels count × 32B <- client-computed queue labels для нужных (session × window) пар
Инварианты RangeSubscribeRequest:
count ≤ max_range_labels_per_request(= 10 000); иное → rejectRangeTooLarge- Labels — 32-байтовые opaque identifiers, хост не проверяет их semantic validity (просто ищет совпадения в Blob Buffer)
- Source account (IBT-authenticated sender) активен в Account Table
- Rate limit:
max_range_subscribes_per_τ₁ = 16per account per окно; превышение → rejectRateLimited
Message type 0x64 — RangeSubscribeResponse
Payload format:
RangeSubscribeResponse:
blob_count 2B <- u16 LE, число найденных blobs
blobs blob_count × BlobEntry
где BlobEntry:
matched_label 32B <- один из labels запроса
blob_size 4B <- u32 LE, размер blob в байтах
blob_data blob_size × B <- encrypted payload
Хост возвращает все blobs из Blob Buffer чей app_id соответствует одному из запрошенных labels (через derivation app_id = SHA-256("mt-app" || label)). Blobs возвращаются в произвольном порядке; клиент matches их к labels через matched_label поле.
Message type 0x65 — RangeSubscribeError
RangeSubscribeError:
error_code 1B <- 0x01 RateLimited, 0x02 RangeTooLarge, 0x03 ResourceExhausted
Validation workflow хоста
- Проверить IBT-аутентификация клиента (уровень 3 для account-only)
- Проверить
count ≤ max_range_labels_per_request - Проверить rate limit
max_range_subscribes_per_τ₁ - Для каждого label в запросе — lookup в локальном Blob Buffer по app_id
- Собрать все matched blobs в response
- Отправить RangeSubscribeResponse (либо RangeSubscribeError при failure)
TTL bound. Blob Buffer имеет TTL = τ₂ (~14 дней). Labels для окон старше τ₂ — в Blob Buffer их уже нет, результат match будет пустой. Клиент может запрашивать любые labels, но имеет смысл запрашивать только до τ₂ назад.
Эффективность на 1B scale
Worst case offline 1440 τ₁:
- 100 sessions × 1440 windows × 2 (double-window derivation) = 288 000 labels на catch-up
- 10 000 labels per request → 29 requests
- 16 per τ₁ rate limit → catch-up за 2 τ₁
Worst case offline 1 τ₂ (полный TTL):
- 100 × 20 160 × 2 = 4.03M labels
- 403 requests → 26 τ₁ → ~26 минут catch-up
Хост load:
- 1000 клиентов × 10K SHA-256 compares = 10M lookups per request cycle
- SQLite-style read ≤ 10 µs per lookup → 100 sec CPU per 1000 clients
- Spread по catch-up window — peak CPU ~10% при одновременном возвращении клиентов после массового offline event
Работает на 1B.
Применимость инвариантов
- [I-1] PQ-secure: SHA-256 label compare + HKDF-SHA-256 label derivation. ✓
- [I-2]: не затронут (client-layer, не consensus). ✓
- [I-3]: labels — client-layer derived, не consensus state. ✓
- [I-5] Commodity hardware: HKDF trivial на любом CPU. ✓
- [I-6] Регуляторная совместимость: RangeSubscribe = bulk read операция, не privacy mixer. Labels сами по себе видны хосту явно. ✓
- [I-7] Минимальная крипто-поверхность: reuse existing HKDF-SHA-256. ✓
- [I-14] State lifecycle: labels ephemeral, blobs через TTL τ₂. Без persistent consensus state. ✓
- [I-15] Time-based scarcity: rate limit через
max_range_subscribes_per_τ₁. ✓ - [I-16] Out-of-band identity binding: ортогонально. ✓
Rate limit rationale
max_range_subscribes_per_τ₁ = 16 при max_range_labels_per_request = 10 000 даёт максимум 160 000 labels в запросах per account per τ₁. Покрывает catch-up после 1 часа offline с запасом. Для более длительного offline клиент делает catch-up за несколько τ₁ — приемлемо.
max_range_labels_per_request = 10 000 — balance между single request capacity и host CPU load per request. 10K SHA-256 lookups ≈ 100 мс CPU на average SQLite — single request processable в реальном времени.
Карточки замыкания механизмов сетевого слоя
Каждый механизм сетевого уровня закрывается стандартной карточкой из 11 пунктов (раздел роли «Замыкание механизмов») плюс проверкой по 15 глобальным инвариантам (раздел роли «Обязательная карточка механизма»). Сетевой слой ортогонален consensus state, поэтому большинство инвариантов помечены n/a единообразно — explicit n/a важнее implicit отсутствия пункта (Gate 13a invariant enumeration completeness применён к карточкам).
Карточка — IBT online proof
Объект: подписанный proof принадлежности к идентичности перед серверным узлом
Создатель: клиент (узел / candidate / account)
Проверяет: серверный узел (lookup по Node Table → Candidate Pool → Account Table)
Формат сериализации: ML-DSA-65 signature (3309 B) над байтовой строкой
"mt-tunnel-online" || server_node_id || floor(W / 2)
Состояние: ephemeral, не хранится; per-connection, отбрасывается при disconnect
Какой root: не входит ни в один root (transport-layer, ортогонален consensus state)
Срок жизни: 2 окна — window slot = current ИЛИ previous (acceptable bound)
Истечение: connection drop; reconnect требует свежего proof
Конфликт: replay protection через `server_node_id` binding к получателю +
window slot bound; cross-context replay блокируется доменным
разделителем `mt-tunnel-online` отдельно от `mt-tunnel-mesh`
Цена злонамеренного: brute-force ML-DSA-65 secret key (NIST level 3 — квантово-эквивалентно
192-битной симметричной стойкости, infeasible)
State transition: не участвует — pure transport gate
Object class: value (transport gate)
Canonical inclusion: no
Can delay change future power: no
Can absence change state: no (no proof = no connection, не state change)
Seed inputs canonical: n/a (нет seed inputs)
Expiry exploitable by streak: no (replay window = 2 окна, slot tied to canonical W)
Temporal anchors bounded: yes (`floor(W / 2)`, нижняя/верхняя границы канонические)
Global invariant check:
[I-1] PQ-secure: yes (ML-DSA-65, NIST level 3)
[I-2] Public financial layer: n/a
[I-3] Deterministic state: n/a (transport-orthogonal)
[I-4] TimeChain independence: n/a
[I-5] Commodity hardware: yes (ML-DSA-65 verify ≪1 мс на commodity CPU)
[I-6] Regulatory compat: yes (стандартный TLS + клиентская auth — паттерн
корпоративных порталов и банковских API,
миллионы серверов в интернете)
[I-7] Minimal crypto surface: yes (использует существующие ML-DSA-65 + SHA-256,
новых примитивов не вводит)
[I-8] Network-bound unpredictability: n/a (auth, не consensus seed)
[I-9] Bit-exact deterministic: n/a (нет численных формул)
[I-10] Single Source of Truth: yes (формула в одном месте — раздел «IBT» выше)
[I-11] Nickname uniqueness: n/a
[I-12] Auction determinism: n/a
[I-13] Deflationary sink: n/a
[I-14] State lifecycle: n/a (ephemeral)
[I-15] Time-based scarcity: yes (anti-spam через window slot rate-limit
на стороне сервера — proof валиден только
в текущем или предыдущем окне)
Status: закрыто
Карточка — IBT mesh proof
Объект: подписанный proof для mesh peer без свежего window_index
Создатель: клиент (узел) в mesh-режиме (BLE / Wi-Fi Aware, без internet)
Проверяет: принимающий mesh peer
Формат сериализации: ML-DSA-65 signature (3309 B) над байтовой строкой
"mt-tunnel-mesh" || peer_node_id || floor(cached_W / 2)
|| mesh_session_nonce
где cached_W: u32, mesh_session_nonce: 32 B
Состояние: ephemeral для самого proof; per-sender persistent set
`used_nonces[sender_pubkey]` для replay tracking
Какой root: не входит ни в один root (transport-layer)
Срок жизни: cached_W валиден в окне `[peer.known_W − 7·τ₁, peer.known_W]`;
свыше — peer отклоняет mesh handshake
Истечение: записи в `used_nonces[sender_pubkey]` старше 7·τ₁ удаляются
(cached_W уже невалиден, повторное использование nonce безопасно)
Конфликт: per-nonce replay tracking — `mesh_session_nonce ∈ used_nonces[sender_pubkey]`
→ silent reject; cross-context replay блокируется доменным
разделителем `mt-tunnel-mesh` отдельно от `mt-tunnel-online`
Цена злонамеренного: brute-force ML-DSA-65 secret key (level 3); расширенный staleness
window 7·τ₁ компенсирован per-nonce tracking — replay одного
и того же proof невозможен повторно
State transition: не участвует — pure transport gate; локальная mutation
`used_nonces` set не входит в consensus state
Object class: value (transport gate)
Canonical inclusion: no
Can delay change future power: no
Can absence change state: no
Seed inputs canonical: n/a
Expiry exploitable by streak: no (TTL cleanup детерминирован cached_W validity)
Temporal anchors bounded: yes (`[known_W − 7·τ₁, known_W]`, обе границы explicit)
Global invariant check:
[I-1] PQ-secure: yes (ML-DSA-65, NIST level 3)
[I-2] Public financial layer: n/a
[I-3] Deterministic state: n/a (локальный set вне consensus root)
[I-4] TimeChain independence: yes (mesh оперирует cached_W из любого предыдущего
online handshake / gossiped proposal,
не требует live TimeChain progression)
[I-5] Commodity hardware: yes (BLE / Wi-Fi Aware есть на любом смартфоне
и ноутбуке; ML-DSA-65 verify дёшев)
[I-6] Regulatory compat: yes (mesh handshake — собственная сетевая
процедура, не privacy mixer)
[I-7] Minimal crypto surface: yes (один доменный сепаратор + существующие
примитивы)
[I-8] Network-bound unpredictability: n/a
[I-9] Bit-exact deterministic: n/a
[I-10] Single Source of Truth: yes (формула в одном месте — раздел «Mesh
transport IBT extension» выше)
[I-11] Nickname uniqueness: n/a
[I-12] Auction determinism: n/a
[I-13] Deflationary sink: n/a
[I-14] State lifecycle: yes — путь 2 (temporal): записи `used_nonces`
удаляются после 7·τ₁ (auto-pruning по
cached_W expiry); локальная Storage Card
для `used_nonces` фиксирует bound
(см. раздел «Локальные сетевые таблицы —
Storage Cards», заполняется отдельной
правкой)
[I-15] Time-based scarcity: yes (acceptable staleness 7·τ₁ — time-based
ограничитель; per-sender quota на nonce
create rate ограничивает spam)
Status: закрыто
Карточка — Bootstrap proof-of-work
Объект: anti-flood защита для подключения к hardcoded genesis bootstrap
узлам, у которых отсутствует Account Table verification
Создатель: клиент (любой ML-DSA-65 keypair) при первом подключении к bootstrap
Проверяет: bootstrap узел (один из 12 hardcoded в Genesis Decree)
Формат сериализации: nonce: 32 B; proof = IBT online proof bytes; верификатор пересчитывает
SHA-256("mt-bootstrap-pow" || proof || nonce) и сравнивает с target
Состояние: ephemeral, отбрасывается после accept либо reject
Какой root: не входит ни в один root
Срок жизни: валиден на время одной попытки handshake; новое подключение требует
новый nonce (фиксированного TTL у самого PoW нет — сервер хранит
recent_nonces для anti-replay в окне τ₁)
Истечение: любой connection close (success либо fail); recent_nonces очищается
на каждой τ₁ boundary
Конфликт: recent_nonces lookup на bootstrap; повтор nonce → reject
Цена злонамеренного: ≈100 мс CPU per попытка (target подобран под этот budget); атакующий
при rate 10 connections/сек тратит 1 CPU-сек/сек = одно постоянно
занятое ядро на каждый bootstrap; 12 bootstrap × 1 ядро = 12 ядер
постоянной нагрузки для distributed flood, что покрывается обычной
sysadmin response (rate-limit на сетевом уровне, fail2ban)
State transition: не участвует
Object class: value (anti-flood gate)
Canonical inclusion: no
Can delay change future power: no
Can absence change state: no
Seed inputs canonical: n/a
Expiry exploitable by streak: no (per-connection, recent_nonces очищается per τ₁)
Temporal anchors bounded: yes (recent_nonces TTL = τ₁)
Global invariant check:
[I-1] PQ-secure: yes (SHA-256 — Grover-resistant до 128 бит,
для anti-flood gate приемлемо)
[I-2] Public financial layer: n/a
[I-3] Deterministic state: n/a (transport-orthogonal)
[I-4] TimeChain independence: yes (PoW верификация локальна, не требует
consensus state; bootstrap должен работать
для впервые подключающегося узла, который
ещё не имеет TimeChain копии)
[I-5] Commodity hardware: yes (SHA-256 grinding ≪100 мс на любом CPU)
[I-6] Regulatory compat: yes (PoW — стандартная anti-DoS техника,
аналог hashcash в email)
[I-7] Minimal crypto surface: yes (только SHA-256 + существующая ML-DSA-65
подпись из IBT proof)
[I-8] Network-bound unpredictability: n/a (нет consensus seed)
[I-9] Bit-exact deterministic: yes — `target` derivation: integer-specified
как `target = (2^256) / difficulty_factor`
где `difficulty_factor` = константа из
Genesis Decree (см. отдельную правку
protocol_params для добавления поля
`bootstrap_pow_difficulty`)
[I-10] Single Source of Truth: yes (формула в одном месте — раздел «Bootstrap
exception» выше)
[I-11] Nickname uniqueness: n/a
[I-12] Auction determinism: n/a
[I-13] Deflationary sink: n/a
[I-14] State lifecycle: yes — путь 2 (temporal): recent_nonces TTL τ₁
[I-15] Time-based scarcity: yes — PoW использует CPU-время как scarce ресурс,
что соответствует time-market принципу
протокола без денежных комиссий
Status: закрыто (с открытым sub-finding на формализацию
`bootstrap_pow_difficulty` в Genesis Decree
`protocol_params` — закроется отдельной правкой
раздела II.5 плана сетевого слоя)
Карточка — Uniform Framing
Объект: транспортный фрейм фиксированного размера, скрывающий
тайминг и размер реальных сообщений Монтаны
Создатель: отправитель (любой узел / candidate / account внутри IBT-сессии)
Проверяет: получатель — структура (1B flags + 2B length + 1021B payload)
и semantic constraints (length ≤ 1021, flags корректны)
Формат сериализации: flags 1B (0x01 data, 0x02 padding, 0x04 continuation;
битовая комбинация data | continuation допустима для
многофреймовых ProtocolMessage); length 2B u16 little-endian
(≤ 1021); payload 1021B (real data до length, далее random
padding до конца frame)
Состояние: ephemeral, не хранится; per-frame отбрасывается после
decrypt + parse + dispatch к ProtocolMessage layer
Какой root: не входит ни в один root (transport-only)
Срок жизни: длительность одного TCP segment / TLS record;
scheduler выдерживает baseline 1 frame/сек на исходящем
соединении, max burst ≤ 8 frames без паузы ≥ 10 мс
Истечение: каждый frame обрабатывается синхронно или drop
при backpressure (drop policy фиксируется в карточке
ProtocolMessage layer)
Конфликт: нет (не подписанный объект; corruption детектится
на уровне TLS MAC, frame с невалидной структурой
дисциплинированно отбрасывается)
Цена злонамеренного: атакующий внутри IBT (т.е. валидно прошедший proof)
может посылать padding фреймы — это рост его
transport quota (см. backpressure rules), не state damage;
external observer не различает data от padding (TLS shield)
State transition: не участвует
Object class: value (transport encapsulation)
Canonical inclusion: no
Can delay change future power: no (frame schedule оперирует локальным кварцем
транспортного стека, outside [I-18] scope)
Can absence change state: no (отсутствие frames = idle connection,
не state change)
Seed inputs canonical: n/a
Expiry exploitable by streak: no (per-frame disposable)
Temporal anchors bounded: n/a (нет привязки к консенсусным окнам)
Global invariant check:
[I-1] PQ-secure: n/a (encapsulation, не cryptographic primitive
— confidentiality обеспечивается TLS
слоем выше; padding bytes из CSPRNG
достаточны без PQ requirement)
[I-2] Public financial layer: n/a
[I-3] Deterministic state: n/a (transport-orthogonal; frame scheduling
non-deterministic by design — иначе
атакующий предсказывает padding pattern)
[I-4] TimeChain independence: yes (frame scheduling использует локальный
кварц, не TimeChain progression)
[I-5] Commodity hardware: yes (1024 B frame × 1 fps = 1 KB/сек на
исходящее соединение; 24 outbound × 1
fps × 1024 B ≈ 13 KB/сек ≈ 33 GB/мес —
приемлемо для домашнего сервера)
[I-6] Regulatory compat: yes (uniform encryption traffic — стандартный
паттерн HTTPS, неотличим от обычного
web-трафика для DPI)
[I-7] Minimal crypto surface: yes (использует только OS CSPRNG, новых
примитивов не вводит)
[I-8] Network-bound unpredictability: n/a (transport, не consensus seed)
[I-9] Bit-exact deterministic: partial — wire format frame structure
integer-specified; frame scheduling
non-deterministic (CSPRNG-based) —
это требование, не bug
[I-10] Single Source of Truth: yes (frame layout в одном месте — раздел
«Uniform Framing» выше)
[I-11] Nickname uniqueness: n/a
[I-12] Auction determinism: n/a
[I-13] Deflationary sink: n/a
[I-14] State lifecycle: n/a (ephemeral)
[I-15] Time-based scarcity: yes — baseline 1 fps на исходящем
соединении сам по себе rate-limit:
attacker не может flood-ить выше
≤8 frames burst + 10 мс пауза;
время — scarce ресурс ограничивающий
throughput
Status: закрыто
Карточка — Transport Randomness
Объект: источник случайности для транспортного слоя
(padding bytes, frame jitter, stem routing choice
в Dandelion++, mesh_session_nonce, bootstrap PoW nonce,
backoff jitter)
Создатель: локальный сетевой стек узла, при каждом случае
где требуется недетерминированный выбор
Проверяет: никто внешне (это локальный random — не verifiable
input; verifiability недостижима для transport
randomness by design — иначе атакующий предсказывает)
Формат сериализации: n/a (внутренний bytes stream, не сериализуется)
Состояние: ephemeral; OS entropy pool управляется ядром,
никаких consensus-state записей
Какой root: не входит ни в один root
Срок жизни: каждый запрос — fresh bytes; entropy pool пополняется
ядром автоматически
Истечение: не применимо — pull-as-needed
Конфликт: нет (внутренний источник; conflicting requests
обслуживаются ядром sequentially)
Цена злонамеренного: compromise OS entropy = full compromise узла на других
уровнях; mitigations — стандартный ОС hardening
(вне scope протокола)
State transition: не участвует
Object class: value (entropy source)
Canonical inclusion: no
Can delay change future power: no
Can absence change state: no
Seed inputs canonical: no — by design; transport randomness
обязана быть unverifiable извне
Expiry exploitable by streak: no
Temporal anchors bounded: n/a
Global invariant check:
[I-1] PQ-secure: yes (OS CSPRNG — современные ядра
используют ChaCha20 / AES-CTR DRBG +
hash-based reseed: post-quantum
symmetric primitives, Grover-resistant
до 128 бит при ≥256-битной seed)
[I-2] Public financial layer: n/a
[I-3] Deterministic state: n/a — transport randomness OBLIGATORILY
non-deterministic; consensus state
использует other randomness sources
([I-8] cemented bundle aggregate)
[I-4] TimeChain independence: yes (OS CSPRNG локален, не зависит от
TimeChain progression)
[I-5] Commodity hardware: yes (OS CSPRNG доступен на любой OS;
hardware RNG (RDRAND, ARM TrustZone)
используется ядром если доступен,
иначе software fallback)
[I-6] Regulatory compat: yes (стандартное OS API)
[I-7] Minimal crypto surface: yes (используется только OS-provided
entropy, никаких custom CSPRNG
реализаций в коде Монтана)
[I-8] Network-bound unpredictability: n/a — explicit boundary: transport
randomness orthogonal к consensus
randomness; их никогда не смешивать
в одной hash composition. PRNG от
node state ЗАПРЕЩЁН для transport
(см. spec строка «Transport Randomness»)
[I-9] Bit-exact deterministic: n/a (non-deterministic by design)
[I-10] Single Source of Truth: yes (правило «OS CSPRNG, не PRNG от node
state» в одном месте — раздел
«Transport Randomness» выше)
[I-11] Nickname uniqueness: n/a
[I-12] Auction determinism: n/a
[I-13] Deflationary sink: n/a
[I-14] State lifecycle: n/a
[I-15] Time-based scarcity: n/a (entropy — не scarce ресурс
на уровне протокола; rate-limited
ядром если pool пуст, что является
OS-level concern)
Status: закрыто
Карточка — Peer selection (выбор пиров)
Объект: процедура подбора набора активных peer-узлов
для данного локального узла, обеспечивающая
устойчивость к eclipse через 4-мерную
diversity-конструкцию
Создатель: локальный сетевой стек узла
Проверяет: локальный сетевой стек (внешней верификации нет —
это локальная политика; внешняя видимость только
через peer exchange)
Формат сериализации: n/a для самой процедуры; PeerRecord (см. spec
раздел «PeerRecord») — 32B node_id + ML-DSA-65
pubkey 1952B + IPv4/v6 + port + start_window
+ last_seen_window + AS-номер + /16 префикс
Состояние: локальная PeerRecord table — две части:
«новые» (от bootstrap / PeerListResponse, ещё не
использованные) и «проверенные» (успешные соединения
в прошлом); хранится в RocksDB вне consensus state
Какой root: не входит ни в один root
Срок жизни: запись хранится пока last_seen_window ≥ current − N
(точное N — параметр локального стека, default 8·τ₁
при отсутствии успешных contact attempts);
автоматическое pruning по этому критерию
Истечение: pruning старых записей; rotation 1 outbound peer per
τ₂ (см. spec «Ротация»); replace при connect failure
> threshold
Конфликт: peer claims конфликтующий node_id с записью в Node
Table при IBT handshake → reject IBT, peer blacklist
на τ₁; конфликт записей в локальной таблице между
«новыми» и «проверенными» — wins «проверенные»
Цена злонамеренного: eclipse требует контроль ≥¾ outbound slots; 4 уровня
diversity (/16, ASN, start_window, role) делают
экономическую стоимость eclipse-атаки order-of-magnitude
выше тривиального Sybil; start_window ограничивает
timing concentration через VDF-барьер регистрации узла
(τ₂ окон sequential SHA-256)
State transition: не участвует (consensus state не меняется)
Object class: value (transport policy)
Canonical inclusion: no
Can delay change future power: no (rotation локальна, не влияет на global
active set)
Can absence change state: no
Seed inputs canonical: n/a (PeerRecord selection из bucket по
локальному secret key — anti-enumeration,
не consensus seed)
Expiry exploitable by streak: no (rotation periodic, не tied к streak)
Temporal anchors bounded: yes (last_seen_window bounded; start_window
verifiable through Node Table при IBT)
Global invariant check:
[I-1] PQ-secure: yes (PeerRecord pubkey ML-DSA-65;
IBT handshake закрывает auth)
[I-2] Public financial layer: n/a
[I-3] Deterministic state: n/a (локальная политика — by design
non-deterministic; разные узлы
имеют разные peer-tables)
[I-4] TimeChain independence: yes (peer selection не зависит от
cementing progress)
[I-5] Commodity hardware: yes (PeerRecord ≈2 KB на запись;
8192 записей × 2 KB = 16 MB —
приемлемо для домашнего сервера)
[I-6] Regulatory compat: yes (стандартный P2P паттерн)
[I-7] Minimal crypto surface: yes (использует существующие ML-DSA-65
+ SHA-256, новых примитивов нет)
[I-8] Network-bound unpredictability: n/a (transport policy, не consensus
seed; PeerRecord selection bucket
из локального secret key — это
anti-enumeration, не consensus
randomness)
[I-9] Bit-exact deterministic: n/a (non-deterministic policy)
[I-10] Single Source of Truth: yes (правила выбора в одном месте —
раздел «Выбор пиров» выше;
PeerRecord layout — раздел
«PeerRecord»)
[I-11] Nickname uniqueness: n/a
[I-12] Auction determinism: n/a
[I-13] Deflationary sink: n/a
[I-14] State lifecycle: yes — путь 2 (temporal): pruning по
last_seen_window TTL; локальная
Storage Card для PeerRecord table
фиксирует hard quota 8192 записей
(см. раздел «Локальные сетевые
таблицы — Storage Cards», открыт
в разделе II.2 плана)
[I-15] Time-based scarcity: yes (start_window-based diversity —
время как scarce ресурс через
VDF-барьер регистрации; rotation
1 peer per τ₂ — time-based)
Status: закрыто
Карточка — Dandelion++ (анонимность отправителя)
Объект: two-phase relay protocol для скрытия источника
user operation (Transfer / Anchor / ChangeKey)
от сетевого наблюдателя
Создатель: отправитель user operation выбирает stem path
(line-graph над outbound peers); каждый узел в
stem ретранслирует к одному random successor
пока не завершится stem TTL → fluff broadcast
всем outbound peers
Проверяет: никто внешне не «верифицирует» Dandelion path
(это привативная процедура); receiver валидирует
user operation подписью независимо от пути
Формат сериализации: operation embedded в ProtocolMessage type 0x01
(Transfer) / 0x03 (ChangeKey) / 0x04 (Anchor)
с дополнительным flag-байтом stem-mode в payload
preamble (см. spec раздел «Dandelion++» — точное
расположение flag фиксируется в Wire Format II.3
binding vectors)
Состояние: ephemeral; per-узел flip-coin per τ₁ выбирает
один random outbound peer как «эпохальный
stem successor» — таблица `stem_successor[τ₁]`
размером 1 запись per epoch
Какой root: не входит ни в один root
Срок жизни: stem path TTL — geometric distribution с
expected hops = 10 (probability 0.1 fluff per hop);
один operation в stem не более 30 hops hard cap
(защита от infinite loop); fluff после TTL —
broadcast
Истечение: stem TTL exhaustion → fluff; loop detection
через operation identifier — повторный приём
одного identifier'а в stem → принудительный fluff
Конфликт: stem peer offline → fallback к fluff немедленно
(не обнулять anonymity путь backtrack)
Цена злонамеренного: atacker контролирующий M of N outbound peers
получает probabilistic tracing — для P(trace) ≥ 0.5
требуется M/N ≥ 0.5 (по Bhattacharya-Schmidt-Wagner
анализ для line-graph stem); diversity constraints
из «Выбор пиров» делают это economically expensive
State transition: не участвует
Object class: value (privacy enhancement)
Canonical inclusion: no
Can delay change future power: no (operation eventually broadcasted via fluff;
stem задерживает propagation на ≤30 hops)
Can absence change state: no
Seed inputs canonical: no (stem successor selection — locally random,
attacker должен not predict; см.
Transport Randomness)
Expiry exploitable by streak: no (geometric TTL — нет exploitable pattern)
Temporal anchors bounded: yes (TTL hard cap 30 hops, stem_successor
rotates per τ₁)
Global invariant check:
[I-1] PQ-secure: n/a (privacy enhancement, не cryptographic
primitive; underlying transport TLS+IBT
закрывает [I-1])
[I-2] Public financial layer: yes — Dandelion++ скрывает только
**первого hop** (входной IP);
финальный recipient + amount в
Transfer остаются publicly visible
после fluff (per [I-2] открытость
финансового слоя сохраняется)
[I-3] Deterministic state: n/a (transport policy)
[I-4] TimeChain independence: yes
[I-5] Commodity hardware: yes (stem_successor table — 1 запись
per τ₁; operation forwarding —
just relay)
[I-6] Regulatory compat: yes — Dandelion++ не privacy mixer
(recipient + amount открыты);
скрывает только сетевой источник
(стандартный network-layer
privacy enhancement, аналог
Tor entry guard concept)
[I-7] Minimal crypto surface: yes (no new crypto primitives)
[I-8] Network-bound unpredictability: n/a
[I-9] Bit-exact deterministic: n/a (probabilistic protocol)
[I-10] Single Source of Truth: yes (stem-fluff state machine
в одном месте — раздел
«Dandelion++» выше)
[I-11..I-13]: n/a
[I-14] State lifecycle: yes — путь 2 (temporal):
stem_successor[τ₁] rotates,
старые записи отбрасываются
[I-15] Time-based scarcity: yes (stem epoch = τ₁; rotation
периодическая)
Status: закрыто
Карточка — NAT Traversal
Объект: процедура установления входящих соединений для
узлов за NAT (домашние провайдеры, мобильные сети)
без статического публичного IP
Создатель: локальный сетевой стек узла за NAT; rendezvous
request к публичному peer для координации
hole-punch
Проверяет: оба peer-а проверяют successful traversal через
normal IBT handshake после hole-punch;
invalid pubkey → reject
Формат сериализации: три механизма (operator choice, не default+fallback):
(a) UPnP/PCP — стандартный port mapping request к
home router; success → external port published
в PeerRecord
(b) AutoNAT detection + hole punching через rendezvous
peer (libp2p AutoNAT v2 protocol; rendezvous —
любой directly-reachable peer)
(c) circuit relay через third peer — fallback для
симметричных NAT где hole-punching невозможен;
relay peer передаёт frames без расшифровки
(TLS+IBT end-to-end сохранены)
Состояние: ephemeral session state per active connection;
external_port в PeerRecord для UPnP path
Какой root: не входит ни в один root
Срок жизни: active connection lifetime; UPnP mapping renew
каждые 30 минут (стандартный TTL)
Истечение: connection close → drop session state;
UPnP mapping release при graceful shutdown
Конфликт: нет (peer-to-peer coordination; conflicting
mappings обрабатываются роутером)
Цена злонамеренного: rendezvous peer узнаёт что узел A пытается
соединиться с узлом B (metadata leak в момент
hole-punch coordination); закрывается выбором
random rendezvous из проверенных peers через
Dandelion-like обфускацию rendezvous selection;
relay peer узнаёт frames volume + timing
(но не содержимое — TLS+IBT защищены)
State transition: не участвует
Object class: value (transport reachability)
Canonical inclusion: no
Can delay change future power: no
Can absence change state: no
Seed inputs canonical: n/a
Expiry exploitable by streak: no
Temporal anchors bounded: yes (UPnP TTL 30 мин — bounded refresh)
Global invariant check:
[I-1] PQ-secure: yes (PQ-security обеспечивается TLS+IBT
слоем; NAT traversal — только
addressing layer)
[I-2] Public financial layer: n/a
[I-3] Deterministic state: n/a
[I-4] TimeChain independence: yes
[I-5] Commodity hardware: yes (UPnP / AutoNAT — стандартные
протоколы home routers / libp2p)
[I-6] Regulatory compat: yes (стандартная P2P практика;
circuit relay — публично известный
паттерн libp2p)
[I-7] Minimal crypto surface: yes (no new crypto primitives —
переиспользует TLS+IBT)
[I-8] Network-bound unpredictability: n/a
[I-9] Bit-exact deterministic: n/a
[I-10] Single Source of Truth: yes (раздел «NAT Traversal» выше)
[I-11..I-13]: n/a
[I-14] State lifecycle: yes — путь 2 (temporal):
session state ephemeral; UPnP
renew TTL bounded
[I-15] Time-based scarcity: n/a (NAT traversal — addressing,
не anti-spam механизм)
Status: закрыто
Карточка — Mesh Transport
Объект: набор протоколов для P2P-сетевания узлов без
интернет-доступа: Bluetooth Low Energy (BLE),
Wi-Fi Aware (NAN), local Wi-Fi multicast
(mDNS-based discovery)
Создатель: локальный mesh-стек узла; advertisement выпускается
периодически (BLE: ≈1 секунда interval; Wi-Fi
Aware: per platform default)
Проверяет: принимающий peer проверяет mesh advertisement
подписью + IBT mesh proof (см. отдельная карточка
«IBT mesh proof»); MeshFrame structure validation
(flags + fragment_index + total_fragments + payload)
Формат сериализации: MeshFrame wire format (см. spec раздел «MeshFrame
wire format»):
flags 1B (включая fragment_continuation bit)
fragment_index 1B
total_fragments 1B (≤ 255)
recipient_hint 32B (0xFF×32 = broadcast)
payload bytes (variable, после fragmentation)
Fragmentation для payload > MTU (BLE MTU 244B
практический; Wi-Fi Aware ≈ 1500B; см. spec
«Fragmentation»)
Состояние: ephemeral mesh session per active peer (BLE GATT
connection; Wi-Fi Aware data path); per-sender
used_nonces для IBT mesh replay tracking
(см. карточку «IBT mesh proof»)
Какой root: не входит ни в один root (transport-only)
Срок жизни: advertisement выпускается каждые 1 сек по умолчанию;
connection — пока physical link жив + IBT proof
валиден; battery management управляет частотой
(см. spec «Battery management» — экспоненциальный
backoff при низком заряде)
Истечение: physical link loss → drop session; battery
saver mode → reduced advertisement frequency
(1/8 baseline при < 20% charge)
Конфликт: ID collision на BLE MAC random → IBT proof
disambiguates (real identity = pubkey, не MAC);
duplicate fragment receipt → discard
Цена злонамеренного: physical proximity required (BLE ≈ 100m line-of-sight,
Wi-Fi Aware ≈ 200m); attacker with proximity
может flood advertisements — закрывается per-sender
rate-limit + IBT mesh proof requirement
(без валидного proof advertisement отбрасывается)
State transition: не участвует
Object class: value (transport reachability)
Canonical inclusion: no
Can delay change future power: no
Can absence change state: no
Seed inputs canonical: n/a
Expiry exploitable by streak: no (battery management deterministic от
charge level, не от network state)
Temporal anchors bounded: yes (cached_window_index в IBT mesh proof
bounded 7·τ₁; advertisement interval
1 сек bounded)
Global invariant check:
[I-1] PQ-secure: yes (IBT mesh proof через ML-DSA-65;
MeshFrame body не содержит
cryptographic primitives —
transport encapsulation only)
[I-2] Public financial layer: n/a
[I-3] Deterministic state: n/a
[I-4] TimeChain independence: yes — критический case: mesh transport
работает БЕЗ live TimeChain
(cached_window_index из любого
предыдущего online connection);
это первичный пример [I-4]
compliance в адвверсарных условиях
(отключение интернета)
[I-5] Commodity hardware: yes (BLE есть на любом смартфоне +
ноутбуке; Wi-Fi Aware на Android
≥8 + iOS опционально; macOS/Linux
имеют BLE через Core Bluetooth /
BlueZ)
[I-6] Regulatory compat: yes (BLE/Wi-Fi Aware — стандартные
radio bands; mesh protocol сам
не privacy mixer — recipient
в Transfer публичен)
[I-7] Minimal crypto surface: yes (переиспользует IBT mesh proof +
SHA-256; новых crypto primitives
не вводит)
[I-8] Network-bound unpredictability: n/a
[I-9] Bit-exact deterministic: partial — MeshFrame wire format
integer-specified (binding KAT
vectors в плане раздела II.3);
advertisement timing
non-deterministic (battery-
dependent)
[I-10] Single Source of Truth: yes (MeshFrame layout — раздел
«MeshFrame wire format»;
fragmentation rules — раздел
«Fragmentation»; discovery —
раздел «Mesh discovery flow»;
battery — раздел «Battery
management»)
[I-11..I-13]: n/a
[I-14] State lifecycle: yes — путь 2 (temporal): mesh sessions
ephemeral, used_nonces TTL =
7·τ₁ (см. IBT mesh card)
[I-15] Time-based scarcity: yes (advertisement interval rate-limit;
battery-aware backoff — time-based
ограничение spam)
Status: закрыто
Карточка — Store-and-Forward
Объект: механизм буферизации сообщений для offline
recipient-ов (получатель временно недоступен —
outage, mobile device асинхронно online);
forwarding через intermediate peers до
целевого recipient
Создатель: отправитель кладёт frame в локальный
sf_buffer + флагует для forwarding; intermediate
peer принимает frames для forward, хранит в
своём sf_buffer пока не доставит
Проверяет: recipient проверяет signature + IBT proof
подделкой/replay; intermediate peer не проверяет
content (encrypted end-to-end через recipient
ML-KEM session key); intermediate peer проверяет
forwarding eligibility через signed rate-limit
ack от recipient (см. spec раздел «Signed rate-
limit acks»)
Формат сериализации: Store-and-Forward envelope (см. spec раздел
«Buffer model»):
recipient_hint 32B
ttl_window u32 LE — окно после которого frame
expirется
fragment_index u8
total_fragments u8
ciphertext bytes (E2E encrypted к recipient)
sender_signature 3309B ML-DSA-65 (для accountability
в rate-limit)
Состояние: локальный sf_buffer (один на узел) — RocksDB
таблица; per-sender quota counter (rate-limit
state); recipient-issued signed acks (TTL = τ₁)
Какой root: не входит ни в один root (transport-only)
Срок жизни: frame expires при `ttl_window < current_window`
(sender выбирает TTL, hard cap protocol-level
= 24·τ₁); per-sender quota counter сбрасывается
каждый τ₁
Истечение: buffer pruning по `current_window > ttl_window`
каждые τ₁/12; quota reset per τ₁
Конфликт: sender exceeds quota → frames отбрасываются
silently (ack не приходит, sender сам определит
из retry timeout); recipient signed ack revokes
forwarding right на N окон (anti-DoS тулинг
recipient-а)
Цена злонамеренного: flood frames с invalid signatures → ML-DSA-65
verify cost ≈ 0.1 мс на commodity CPU; per-sender
quota ограничивает rate; signed ack mechanism
позволяет recipient revoke forwarding privilege;
buffer hard quota (Storage Card — открыт в II.2)
ограничивает total disk usage
State transition: не участвует
Object class: value (transport buffering)
Canonical inclusion: no
Can delay change future power: no (forwarding не влияет на consensus
state; recipient финализирует через
normal proposal mechanism)
Can absence change state: no
Seed inputs canonical: n/a
Expiry exploitable by streak: no (TTL hard cap 24·τ₁, quota reset
deterministic)
Temporal anchors bounded: yes (ttl_window bounded; quota per τ₁
bounded; recipient ack TTL τ₁)
Global invariant check:
[I-1] PQ-secure: yes (sender signature ML-DSA-65;
ciphertext через ML-KEM session
key к recipient — оба PQ)
[I-2] Public financial layer: n/a — Store-and-Forward для arbitrary
messaging payloads (включая
app-layer); финансовые операции
в SF buffer обычным путём
(Transfer broadcast + finality
через consensus)
[I-3] Deterministic state: n/a (локальный buffer вне consensus
root)
[I-4] TimeChain independence: yes (SF buffer работает с cached
window_index в mesh контексте)
[I-5] Commodity hardware: yes (sf_buffer ≤ 1 GB по hard quota;
ML-DSA-65 verify дёшев)
[I-6] Regulatory compat: yes (стандартный store-and-forward
паттерн email / Matrix /
Threema; не privacy mixer)
[I-7] Minimal crypto surface: yes (переиспользует ML-DSA-65 +
ML-KEM-768 + SHA-256; новых
примитивов нет)
[I-8] Network-bound unpredictability: n/a
[I-9] Bit-exact deterministic: partial — envelope wire format
integer-specified (binding KAT
vectors в плане II.3); buffer
eviction policy non-deterministic
(LRU + quota)
[I-10] Single Source of Truth: yes (envelope layout — раздел «Buffer
model»; quota — «Per-sender
quota»; ack format — «Signed
rate-limit acks»; forwarding
algorithm — отдельный раздел;
policies — «Buffer policies»)
[I-11..I-13]: n/a
[I-14] State lifecycle: yes — comb (1+2+3): cost-based barrier
n/a по [I-15]; temporal pruning
по ttl_window (путь 2); hard
quota на total buffer size
(путь 3 — Storage Card в II.2);
per-sender quota (путь 3 again)
[I-15] Time-based scarcity: yes — three-layer time defense:
(a) frame TTL ≤ 24·τ₁;
(b) per-sender quota per τ₁;
(c) signed ack window TTL τ₁
Status: закрыто
Карточка — ProtocolMessage envelope
Объект: универсальная транспортная обёртка для всех
сообщений Монтаны внутри IBT-сессии (поверх
Uniform Framing); дискриминатор msg_type +
request/response correlation
Создатель: любой узел / candidate / account внутри
активной IBT-сессии
Проверяет: получатель — структура header (1B msg_type +
1B msg_version + 8B request_id u64 LE +
4B payload_length u32 LE) + payload bounds
(≤ 2^32 − 1 байт; практически limited по
backpressure rules — открыто в плане II.5);
payload validation per msg_type (см. карточку
«Реестр типов сообщений» ниже)
Формат сериализации: 14B fixed header + payload (variable).
msg_version = 1 для всех v3X.x; изменение
wire format → increment + protocol version
upgrade
Состояние: ephemeral; при request/response — request_id
таблица для correlation в течение typical
response window τ₁/2 (см. spec «Connection
lifecycle» timeouts)
Какой root: не входит ни в один root (transport-layer)
Срок жизни: один request/response pair либо one-way gossip
propagation; pending request entries TTL = τ₁
Истечение: request_id timeout → drop pending entry,
error reported to caller
Конфликт: duplicate request_id от того же peer → reject
second; unknown msg_type → log + ignore
(forward compatibility); unknown msg_version
→ respond unsupported_version + disconnect
Цена злонамеренного: flood unknown msg_type — peer обязан
log+ignore (нельзя amplify); flood с invalid
payload — payload_length validated до
аллокации, oversize → reject + peer
blacklist на N·τ₁ (точные параметры — план II.5)
State transition: не участвует (consensus state не меняется
самим envelope; payload может содержать
consensus-bound объекты — их state transitions
фиксируются в их собственных карточках в
основной части спеки)
Object class: value (transport encapsulation)
Canonical inclusion: no
Can delay change future power: no
Can absence change state: no
Seed inputs canonical: n/a
Expiry exploitable by streak: no (request TTL deterministic)
Temporal anchors bounded: yes (request TTL τ₁ bounded)
Global invariant check:
[I-1] PQ-secure: yes (header не содержит crypto;
payloads с подписями
используют ML-DSA-65)
[I-2] Public financial layer: yes (envelope не скрывает
финансовый payload —
Transfer/Anchor/etc видны
в plain после IBT decryption)
[I-3] Deterministic state: yes — wire format integer-specified
byte-exact; cross-implementation
совместимость гарантирована
binding KAT vectors
(план II.3)
[I-4] TimeChain independence: yes (envelope agnostic к
consensus state)
[I-5] Commodity hardware: yes (header parsing — несколько
integer reads; payload
processing per msg_type)
[I-6] Regulatory compat: yes (стандартный
type-length-value protocol
паттерн)
[I-7] Minimal crypto surface: yes (envelope сам не вводит
crypto — все crypto в
IBT layer и payload-объектах)
[I-8] Network-bound unpredictability: n/a (envelope, не consensus seed)
[I-9] Bit-exact deterministic: yes — Gate 13a invariants
enumeration:
msg_type ∈ valid registry
(0x01, 0x03, 0x04, 0x10,
0x20–0x22, 0x40–0x42,
0x50–0x51, 0x60–0x65,
0xF0–0xF1, 0xFF;
реестр fixed в spec)
msg_version = 1
request_id ∈ uint64 (8 LE)
payload_length ∈
[0, 2^32 − 1]
payload bytes count ==
payload_length
binding KAT vectors —
план II.3
[I-10] Single Source of Truth: yes (envelope layout — раздел
«Protocol Message Layer»)
[I-11..I-13]: n/a
[I-14] State lifecycle: yes — путь 2 (temporal): pending
requests TTL τ₁
[I-15] Time-based scarcity: yes (request TTL τ₁; backpressure
rules — план II.5)
Status: закрыто (с открытым sub-finding на
backpressure rules + per-msg-type
rate-limit constants — план II.5)
Карточка — Реестр типов сообщений (групповая)
Объект: унифицированная trait над 18 message-type кодами,
сгруппированными в 6 категорий по семантике;
каждая категория имеет общие validation +
lifecycle характеристики
Создатель: определяется per-категория (см. ниже)
Проверяет: определяется per-категория
Формат сериализации: каждый payload имеет integer-specified layout
в соответствующем разделе спеки + binding KAT
vector в плане II.3 (1–3 vectors per type)
Категории:
A. Consensus objects (gossip) — 7 кодов
Коды: 0x01 Transfer | 0x03 ChangeKey | 0x04 Anchor |
0x10 NodeRegistration | 0x20 BundledConfirmation |
0x21 VDF_Reveal | 0x22 Proposal
Создатель: user / node — подписывает соответствующим keypair
Проверяет: получатель проверяет подпись + структурные инварианты
(см. карточки этих объектов в основной части спеки —
«Account — содержимое блока», «Proposal», «VDF Reveal
и лотерея», «Регистрация окна», и т.д.)
Lifecycle: объекты cemented через consensus path; envelope
ephemeral
Категория: one-way gossip; request_id = 0
B. Fast Sync — 3 кода
Коды: 0x40 FastSyncRequest | 0x41 FastSyncResponse |
0x42 FastSyncError
Создатель: узел запрашивает snapshot (Request) либо отвечает
chunk delivery (Response/Error)
Проверяет: запросчик собирает chunks по chunk_index, верифицирует
Merkle root против proposal_W
Lifecycle: request/response; pending request TTL = τ₁
Категория: request/response correlation через request_id
C. Peer Discovery — 2 кода
Коды: 0x50 PeerListRequest | 0x51 PeerListResponse
Создатель: запрашивающий узел (Request) / отвечающий peer (Response)
Проверяет: получатель PeerListResponse валидирует ≤ max_count
записей + структуру PeerEntry (59B fixed)
Lifecycle: request/response; PeerEntry data применяется к локальной
PeerRecord table (см. карточку «Peer selection»)
Категория: request/response
D. App Lookup — 3 кода
Коды: 0x60 BatchLookupRequest | 0x61 BatchLookupResponse |
0x62 BatchLookupError
Создатель: account клиент (Request) / host узел (Response/Error)
Проверяет: спека «Batch Lookup Protocol» raздел «Validation
workflow хоста» определяет проверки; включая [I-15]
per-account rate-limit
Lifecycle: request/response; результаты ephemeral у клиента
Категория: request/response; access level 3 IBT (account)
E. App Subscription — 3 кода
Коды: 0x63 RangeSubscribeRequest | 0x64 RangeSubscribeResponse |
0x65 RangeSubscribeError
Создатель: account клиент (Request) / host (Response/Error)
Проверяет: спека «Label Rotation + Range Subscribe Protocol» раздел
«Validation workflow хоста»; включая label rotation
formula + per-account rate-limit
Lifecycle: request/response; client сохраняет blob_count blobs
локально для catch-up
Категория: request/response; access level 3 IBT
F. Liveness — 3 кода
Коды: 0xF0 Ping | 0xF1 Pong | 0xFF Bye
Создатель: любая сторона соединения
Проверяет: получатель Pong отвечает Pong (no payload); Bye —
graceful shutdown
Lifecycle: ephemeral
Категория: one-way (Bye) либо request/response (Ping/Pong)
с быстрым TTL (получатель должен ответить до конца
текущего τ₁ у получателя)
Состояние: per-категория — см. соответствующие карточки
существующих объектов (категория A) либо
ephemeral (категории B-F)
Какой root: категория A — payload объекты cemented через
normal consensus root (Account/Node chains,
proposal hash chain); категории B-F — не
входят
Срок жизни: категория A — permanent в consensus state;
категории B-F — ephemeral
Истечение: per-категория
Конфликт: неизвестный msg_type → log+ignore (forward
compat); невалидный payload per type →
reject + peer penalty
Цена злонамеренного: flood с невалидными payloads:
ML-DSA-65 verify ≈ 0.1 мс — пер-IBT-сессия
rate-limit (план II.5) ограничивает damage;
invalid structure detected до crypto verify
через Gate 13a invariants для каждого типа
State transition: категория A — apply через consensus path
(apply_proposal соответствующих объектов);
категории B-F — не участвуют
Object class: per-категория (mostly value)
Canonical inclusion: A: yes (в proposal либо chain entries);
B-F: no
Can delay change future power: A: no (objects уже сформированы;
задержка propagation = задержка
cementing, value-delay не power);
B-F: no
Can absence change state: no
Seed inputs canonical: per object (категория A) — см.
карточки в основной части спеки
Expiry exploitable by streak: no
Temporal anchors bounded: per object категория A;
категории B-F: yes (request TTL τ₁)
Global invariant check (агрегированно по категориям):
[I-1] PQ-secure: yes (категория A объекты подписаны
ML-DSA-65; категории B-F payloads
не содержат crypto primitives
либо переиспользуют ML-DSA-65)
[I-2] Public financial layer: yes (Transfer / Anchor публичны
в payload)
[I-3] Deterministic state: yes (каждый payload integer-
specified, binding KAT vectors
в плане II.3)
[I-4] TimeChain independence: yes (Fast Sync, Peer Discovery
работают независимо от cementing
progress)
[I-5] Commodity hardware: yes
[I-6] Regulatory compat: yes
[I-7] Minimal crypto surface: yes (no new primitives — категория
A переиспользует payload-
specific signatures, категории
B-F не вводят crypto)
[I-8] Network-bound unpredictability: per object категория A — см. их
карточки в основной спеке
(Proposal, VDF_Reveal, и т.д.)
[I-9] Bit-exact deterministic: yes для всех 18 кодов — закрытие
через binding KAT vectors
(план II.3, conformance status
«pending» до закрытия II.3)
[I-10] Single Source of Truth: yes (реестр в одном месте — раздел
«Protocol Message Layer»;
payload formats — каждый в
своём разделе)
[I-11..I-13]: n/a (не nickname / auction /
monetary mechanisms)
[I-14] State lifecycle: категория A — через apply_proposal
существующих объектов;
категории B-F — ephemeral
[I-15] Time-based scarcity: yes (per-IBT-сессия rate-limits
в плане II.5; категория D/E
имеют explicit per-account
rate-limits в spec)
Status: закрыто (с conformance pending по
[I-9] до закрытия плана II.3 binding
KAT vectors; и pending backpressure
constants до плана II.5)
Локальные сетевые таблицы — Storage Cards
Сетевой слой создаёт локальные персистентные таблицы вне consensus state ([I-3] не нарушается — их derivation локальна, не входит в state_root). Они НЕ покрываются разделом «Storage Cards per persistent table» (который про consensus state per [I-14]), но ОБЯЗАНЫ иметь собственные Storage Cards adapted для local-state контекста: размер записи, growth model, lifecycle / eviction, hard quota, total disk usage. Без этих карточек оператор узла не знает требования к диску для node-runtime; реализация может игнорировать quota и raise OOM на длительной работе.
Формат адаптирован для local-state: cost-based фрагменты помечаются n/a единообразно (per [I-15] денежного отказа сетевого слоя), защита через time-based / quota механизмы.
Storage Card — PeerRecord table
Таблица: PeerRecord (локальный сетевой кэш peer-узлов)
Operation создающая запись: приём PeerListResponse (msg_type 0x51) либо
bootstrap connection success
Платит creation cost: none (локальный append; per-sender rate-limit
≤ 1 PeerListRequest per τ₁ ограничивает
rate притока)
Размер записи (bytes): ≈ 2096 B
(32B node_id + 1952B ML-DSA-65 pubkey +
16B IPv6/IPv4 + 2B port + 8B start_window +
8B last_seen_window + 4B AS_number +
16B /16-prefix marker + 6B reserved/padding +
indexing overhead RocksDB ≈ 50 B)
Secondary resources per record: index entry (node_id → record offset) ≈ 50 B;
IP-bucket index (для diversity selection)
≈ 30 B
Cost per record: n/a ([I-15] денежного отказа)
Lifecycle condition: путь 2 (temporal) — pruning при
`last_seen_window < current_window − N`
где N = 8·τ₁ default (параметр локального
стека, не consensus); путь 3 (hard quota)
— total ≤ 8192 records
Eviction policy: при достижении 8192 records — LRU eviction
по last_seen_window (oldest first); rotation
1 outbound peer per τ₂ (см. spec «Ротация»)
обновляет last_seen_window для активных
Total bytes hard cap: ≈ 8192 × 2096 B ≈ 17 MB + indices ≈ 0.7 MB
≈ 18 MB total
[I-14] путь: 2+3 (temporal + hard quota)
Sabotage time-budget атаки: attacker контролирующий ≥1 connected peer
посылает PeerListResponse с 64 fake records
per τ₁; max input rate per peer = 64 records
/ τ₁ = 64 / 60 ≈ 1.07 records/сек;
заполнение 8192 records требует ≈ 7600 сек
≈ 2 часа sustained от одного peer; LRU
eviction вытесняет старые «проверенные»
записи только при total ≥ 8192 — приоритет
«проверенных» через explicit policy
(см. spec «Адресный менеджер»); damage
ограничен нарушением diversity, не denial
of service
Sabotage asymmetry: в пользу сети — eviction приоритезирует
проверенные records; full eclipse требует
координированной атаки множества peers с
diversity bypass
Existing pruning consistent: yes — current spec раздел «Адресный
менеджер» уже описывает приоритизацию
проверенных peers; Storage Card formalizes
hard quota
[I-14] compliance status: закрыто
Storage Card — used_nonces table (mesh IBT replay tracking)
Таблица: used_nonces[sender_pubkey] — set of
mesh_session_nonce per sender
(per IBT mesh proof — см. карточку)
Operation создающая запись: приём валидного mesh IBT proof — добавление
`mesh_session_nonce` в set данного sender
Платит creation cost: none (требует только pre-validated IBT proof
— sender уже потратил CSPRNG generation
+ ML-DSA-65 sign cost)
Размер записи (bytes): ≈ 80 B per nonce
(32B nonce + 16B observed window_index +
16B sender_pubkey hash как index key +
indexing overhead RocksDB ≈ 16 B)
Secondary resources per record: index entry (sender_pubkey → nonce list)
≈ 1952 B per unique sender (pubkey storage)
+ 16 B per nonce in list
Cost per record: n/a
Lifecycle condition: путь 2 (temporal) — записи старше
`current_window − 7·τ₁` удаляются;
cleanup runs каждые τ₁/12
Eviction policy: TTL-based; при overflow soft cap (см. ниже)
— drop nonces oldest first
Total bytes hard cap: soft cap = 1 MB per узел;
при достижении: per-sender quota
enforce ≤ 64 nonces per sender per 7·τ₁
window (sender отправляющий >64
mesh handshakes per 7·τ₁ — анонимизированно
rate-limited); hard cap = 4 MB total —
при достижении узел отказывает в новых
mesh handshakes до cleanup
[I-14] путь: 2+3 (temporal TTL + hard quota)
Sabotage time-budget атаки: attacker генерирует 64 unique nonces per
7·τ₁ × τ₁ = 60 сек = ≈ 0.15 nonces/сек на
одну identity; для заполнения soft cap 1 MB
/ 80 B = 12500 nonces / 64 per identity
= 196 unique attacker identities × 7·τ₁ × 60s
= 82440 сек ≈ 23 часа sustained для soft cap;
для hard cap 4 MB ≈ 92 часа; обнаруживается
через monitoring before exhaustion
Sabotage asymmetry: в пользу сети — per-sender quota плюс
hard quota делает atak uneconomical
и detection-friendly
Existing pruning consistent: yes — IBT mesh card уже описывает
TTL 7·τ₁; Storage Card formalizes per-sender
quota + hard cap
[I-14] compliance status: закрыто
Storage Card — sf_buffer (Store-and-Forward buffer)
Таблица: sf_buffer — RocksDB таблица
forwarding-pending frames
Operation создающая запись: приём Store-and-Forward envelope от sender
с валидной sender_signature + recipient
отсутствует locally (либо sender flagged
store-and-forward)
Платит creation cost: none ([I-15]); защита через per-sender quota
Размер записи (bytes): envelope structure ≈ 3500 B avg
(32B recipient_hint + 4B ttl_window +
1B fragment_index + 1B total_fragments +
ciphertext avg 100B (small messages) к
1100B (large MeshFrame fragment) +
3309B sender_signature ML-DSA-65 +
indexing overhead RocksDB ≈ 50 B)
Secondary resources per record: index entry (recipient_hint → record offset)
≈ 50 B; per-sender quota counter ≈ 32 B
per active sender
Cost per record: n/a
Lifecycle condition: путь 2 (temporal) — pruning при
`current_window > ttl_window`; cleanup
каждые τ₁/12
Eviction policy: при достижении hard quota — drop по
policy «oldest TTL first» среди не-VIP
records (VIP = recipient в локальном
contact whitelist оператора); per-sender
quota — каждый sender ≤ 256 frames per τ₁
Total bytes hard cap: 1 GB per узел (operator-configurable
но default 1 GB); при достижении —
reject new SF envelopes от не-VIP
senders до cleanup
[I-14] путь: 2+3+3 (temporal + per-sender quota +
total hard quota)
Sabotage time-budget атаки: attacker с одной identity = 256 frames
per τ₁ × 3500 B = 896 KB/τ₁ ≈ 14.9 KB/sec;
для hard cap 1 GB / 256 frames per sender
per τ₁ = 4096 unique identities × 256
frames per τ₁ × 3500 B = 1 GB достижим за
один τ₁ если 4096 identities одновременно
активны; защита — diversity constraint
на принимаемые connections (peer selection
card) делает 4096 simultaneous
attacker-controlled connections нереальным
без сильного eclipse
Sabotage asymmetry: защита через combination — per-sender quota
+ diversity на connection layer + signed
rate-limit acks от recipient (recipient
может revoke forwarding right);
multi-layered defense
Existing pruning consistent: yes — Store-and-Forward card уже описывает
per-sender quota + signed acks + TTL;
Storage Card formalizes hard cap 1 GB
[I-14] compliance status: закрыто
Storage Card — bootstrap recent_nonces (PoW anti-replay) + peer blacklist
Таблица: bootstrap_recent_nonces (per-bootstrap-узел)
+ peer_penalty_table (для protocol violation
blacklist; см. spec «Retry policy»)
Operation создающая запись: (a) recent_nonces — приём bootstrap PoW
nonce при handshake attempt
(b) peer_penalty — peer disconnected
с reason 0x04 (protocol violation)
Платит creation cost: (a) ≈ 100 мс CPU PoW per attempt
(см. карточку Bootstrap PoW);
(b) none — penalty entry создаётся
passively при IBT fail или
protocol violation event
Размер записи (bytes): (a) ≈ 80 B per nonce (32B nonce +
16B timestamp_window + indexing 32B);
(b) ≈ 100 B per peer_id
(32B node_id + 8B blacklist_until_window
+ 8B reason_code + 16B observed_event +
indexing 36B)
Secondary resources per record: minimal — flat tables
Cost per record: (a) compute-bound (≈100 мс CPU PoW —
time-based scarcity);
(b) n/a
Lifecycle condition: (a) путь 2 (temporal) — recent_nonces TTL
= τ₁; cleanup каждые τ₁/12;
(b) путь 2 (temporal) — penalty TTL
от 1·τ₁ (IBT fail) до 24·τ₁
(protocol violation reason 0x04)
Eviction policy: TTL-based; hard cap не критичен из-за
rate-limit через PoW cost (a) и
peer-event rate (b)
Total bytes hard cap: (a) per-bootstrap-узел: при flood-rate
10 connections/сек × τ₁ = 600 entries
× 80 B = 48 KB; per τ₁ peak; cleanup
возвращает к baseline
(b) при peak 1000 blacklisted peers
× 100 B = 100 KB
Total ≤ 200 KB sustained
[I-14] путь: 2 (temporal через TTL); rate-limit через
PoW (a) + event rate (b)
Sabotage time-budget атаки: (a) рассчитано в карточке Bootstrap PoW
— ≈ 12 cores sustained для distributed
flood, обнаруживается на сетевом слое
(b) attacker не может flood penalty
table — она пишется реактивно на
legitimate violation events; attacker
контролирующий N peers может выдавать
≤ N protocol violations parallel,
bound через Sybil-stake-cost узла
регистрации (τ₂ окон VDF)
Sabotage asymmetry: в пользу сети
Existing pruning consistent: yes — spec «Retry policy» определяет
TTL для penalty; Storage Card formalizes
rates
[I-14] compliance status: закрыто
Binding KAT vectors сетевого слоя
Каждый вектор фиксирует пару (canonical input, expected byte-exact output) для cross-implementation conformance per [I-9]. Inputs полностью integer-specified в спеке. Expected outputs (TBD-A) генерируются reference implementation в Phase A плана M6 (mt-net::wire) и заполняются параллельным spec patch — до этого момента vectors в статусе conformance pending.
Методология генерации (для Phase A reference impl): запустить encode/decode/sign функцию с указанными inputs, capture byte stream, hex-кодировать, заменить TBD-A: <vector_id> на реальный hex в спеке тем же commit где добавляется test fixtures в mt-net::wire::tests.
A. ProtocolMessage envelope (3 vectors)
Vector A1: empty payload, msg_type Ping, request_id = 0
Input:
msg_type = 0xF0
msg_version = 0x01
request_id = 0x0000000000000000 (u64 LE)
payload_length = 0x00000000 (u32 LE)
payload = (empty)
Expected output (hex): f0 01 00 00 00 00 00 00 00 00 00 00 00 00
(mt-net::tests::test_vectors::vector_a1, byte-exact)
Vector A2: typical Transfer payload (1 KB), msg_type 0x01, request_id = 42
Input:
msg_type = 0x01
msg_version = 0x01
request_id = 42 = 0x2A00000000000000 (u64 LE)
payload_length = 1024 = 0x00040000 (u32 LE)
payload = byte_repeat(0xAB, 1024)
Expected output (hex):
header (14 B): 01 01 2a 00 00 00 00 00 00 00 00 04 00 00
payload (1024 B): byte_repeat(0xAB, 1024) (mt-net::tests::test_vectors::vector_a2)
total len: 1038 B
Vector A3: maximum payload_length boundary, msg_type 0x41 FastSyncResponse
Input:
msg_type = 0x41
msg_version = 0x01
request_id = 0xFFFFFFFFFFFFFFFF (u64 LE)
payload_length = 0xFFFFFFFF (u32 LE) — represents 4 GB-1; semantic
reserved для future protocol upgrade; тест проверяет
ТОЛЬКО header encoding и rejection rule (получатель
обязан reject до allocation per backpressure,
см. план II.5)
payload = (test only header — payload bytes не требуются)
Expected output (hex, header only 14 B):
41 01 ff ff ff ff ff ff ff ff 00 00 00 00
(mt-net::tests::test_vectors::vector_a3, byte-exact)
B. IBT proofs (3 vectors)
Vector B1: IBT online proof — fixed (sk, server_node_id, current_window)
Input:
domain = "mt-tunnel-online" (utf-8 bytes)
server_node_id = 32 B = byte_repeat(0x42, 32)
window_index W = 1000 (u64); floor(W / 2) = 500 = 0x01F4 в derivation
derivation seed = "mt-tunnel-online" || server_node_id || u64_LE(500)
= total 16 + 32 + 8 = 56 B
sk seed = SHA-256("mt-test-seed" || "vector-B1") — fixed deterministic
ML-DSA-65 keypair derivation per ML-DSA-65 KeyGen ξ ∈ B32
Expected output (hex):
seed (32 B): f6 40 57 69 ec bf 3d 1f 5b 65 93 c9 71 f1 41 09
ef 9d 57 62 8b fc 46 b8 f4 d5 c0 b6 6d 0f f1 b9
sha256(pk): ee 74 16 1e ee dc f4 61 89 73 96 bb e6 55 bc 9c
35 39 f6 15 a3 ed ce f9 f8 7a 9e 58 82 b3 00 c2
sha256(proof signature 3309B): ac 26 a9 ca 84 a9 ae ba 3a af 2f 3f c9 ba 2f 0b
e9 0c 6d 98 f6 55 ad db 0f 87 5b ca ad ff ef da
(mt-net::tests + reference impl byte-exact, regenerated after rename
mt-tunnel → mt-tunnel-online per critic-fix P-C2)
Vector B2: IBT mesh proof — fixed (sk, peer_node_id, cached_window, nonce)
Input:
domain = "mt-tunnel-mesh"
peer_node_id = 32 B = byte_repeat(0x33, 32)
cached_window_index = 5000 (u64); floor(5000 / 2) = 2500
mesh_session_nonce = 32 B = byte_repeat(0x77, 32)
derivation message = "mt-tunnel-mesh" || peer_node_id ||
u64_LE(2500) || mesh_session_nonce
= total 14 + 32 + 8 + 32 = 86 B
sk seed = SHA-256("mt-test-seed" || "vector-B2")
Expected output (hex):
sha256(proof) — без изменения (B2 использует mt-tunnel-mesh, не
затронут rename); reference value preserved:
51 98 f8 34 ad a3 af 80 bf 51 82 f0 ec b9 1b 38
9b 70 93 ff 82 93 2e 90 07 3a 30 47 36 14 0b 8c
Vector B3: Bootstrap PoW combination — IBT proof + PoW nonce
Input:
base IBT proof = output Vector B1.proof (sha256 ac26a9ca... per новый B1)
nonce = 0x0000000000000000 (u64 LE) — start search
target derivation = (2^256) / difficulty_factor где
difficulty_factor = 2^16 = 65536 для test
(production value — план II.5 в protocol_params.
bootstrap_pow_difficulty)
Expected output:
target (32 B big-endian): 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(= 2^240 для bootstrap_pow_difficulty = 65 536 = 2^16)
found_nonce: 48 949 (decimal; 0x35bf000000000000 LE)
found_hash (32 B): 00 00 cb 8b 53 f7 e6 a5 ab 66 b2 a7 d2 5d 82 68
0d b7 f3 d4 6a 0a ea 1b 9d 9d 74 67 2d 6b da 23
(mt-net::tests + reference impl byte-exact, regenerated after B1 rename
per critic-fix P-C2)
C. Per-msg-type encode/decode (18 × 1 vector — minimal coverage)
Для каждого type — один canonical input с typical payload, expected envelope+payload hex.
Vector C-0x01 (Transfer Mode A — typical 64 B payload)
Input payload struct: см. spec раздел «Перевод» Transfer Mode A layout
sender_id = byte_repeat(0x11, 32)
receiver_id = byte_repeat(0x22, 32)
amount_nj = 1_000_000 (u64 LE) = 0x40420F0000000000
nonce_index = 0 (u8)
prev_hash = byte_repeat(0xCC, 32)
sender_signature = byte_repeat(0xDD, 3309) — placeholder для test
canonical encode per spec → 32+32+8+1+32+3309 = 3414 B
Wrapped in envelope:
msg_type = 0x01
msg_version = 0x01
request_id = 0
payload_length = 3414 = 0x56430000 (u32 LE)
Expected output (hex): TBD-A: C-0x01
Vector C-0x03 (ChangeKey)
Input payload: см. spec «ChangeKey» layout — typical
Expected output: TBD-A: C-0x03
Vector C-0x04 (Anchor — 1 KB content hash + signature)
Input payload: см. spec «Anchor» layout — typical
Expected output: TBD-A: C-0x04
Vector C-0x10 (NodeRegistration)
Input payload: см. spec «Регистрация окна» NodeRegistration layout
Expected output: TBD-A: C-0x10
Vector C-0x20 (BundledConfirmation)
Input payload: см. spec «Confirmations» BundledConfirmation layout
Expected output: TBD-A: C-0x20
Vector C-0x21 (VDF_Reveal)
Input payload: см. spec «Валидация VDF_Reveal» layout
Expected output: TBD-A: C-0x21
Vector C-0x22 (Proposal)
Input payload: см. spec «Proposal» layout — typical с pre-defined
BundledConfirmation hash + state_root + node_signature
Expected output: TBD-A: C-0x22
Vector C-0x40 (FastSyncRequest)
Input payload:
anchor_window = 12345 (u64 LE)
resume_offset = 0 (u64 LE)
Expected output (hex, 16 B): 39 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(mt-net::tests::test_vectors::vector_c_0x40_fastsync_request, byte-exact)
Vector C-0x41 (FastSyncResponse — single chunk)
Input payload (per spec FastSyncResponse chunk layout):
chunk_index = 0 (u32 LE)
total_chunks = 1 (u32 LE)
table_id = 0x01 (Account)
record_count = 1
records = 1 × AccountRecord byte-encoded (см. AccountRecord
layout)
Expected output (hex, 77 B):
header (13 B): 00 00 00 00 01 00 00 00 01 01 00 00 00
records (64 B): byte_repeat(0x55, 64)
(mt-net::tests::test_vectors::vector_c_0x41_fastsync_response_chunk)
Vector C-0x42 (FastSyncError)
Input payload:
code = 0x01 (snapshot_unavailable)
message = "anchor_window 12345 not retained" (utf-8 bytes,
len ≤ 255)
Expected output (hex, 34 B): 01 20 61 6e 63 68 6f 72 5f 77 69 6e 64 6f 77 20
31 32 33 34 35 20 6e 6f 74 20 72 65 74 61 69 6e
65 64
(mt-net::tests::test_vectors::vector_c_0x42_fastsync_error, byte-exact)
Vector C-0x50 (PeerListRequest)
Input payload:
max_count = 64 = 0x4000 (u16 LE)
Expected output (hex, 2 B): 40 00
(mt-net::tests::test_vectors::vector_c_0x50_peer_list_request, byte-exact)
Vector C-0x51 (PeerListResponse — 3 PeerEntry)
Input payload:
count = 3 = 0x0300 (u16 LE)
peers = 3 × PeerEntry (59 B each — fixed):
peer 1: ip_version=0x04, ip=0.0.0.0.0.0.0.0.0.0.0.0.10.0.0.1
port=4242, node_id=byte_repeat(0xAA,32),
start_window=100 (u64 LE)
peer 2: ip_version=0x06, ip=fe80::1 padded to 16B,
port=4242, node_id=byte_repeat(0xBB,32),
start_window=200 (u64 LE)
peer 3: ip_version=0x04, ip=10.0.0.2 padded,
port=4243, node_id=byte_repeat(0xCC,32),
start_window=300 (u64 LE)
Expected output (hex, 179 B):
count u16 LE (2 B): 03 00
peer 1 (59 B): 04 + 12·00 + 0a 00 00 01 + 92 10 + AA·32 + 64·00·7
peer 2 (59 B): 06 + fe 80 + 13·00 + 01 + 92 10 + BB·32 + c8·00·7
peer 3 (59 B): 04 + 12·00 + 0a 00 00 02 + 93 10 + CC·32 + 2c 01·00·6
(mt-net::tests::test_vectors::vector_c_0x51_peer_list_response_3_entries, byte-exact)
Vector C-0x60 (BatchLookupRequest)
Input payload (per spec «Batch Lookup Protocol»):
query_type = 0x01 (account_id lookup)
count = 2
queries = 2 × 32 B account_id queries
Expected output: TBD-A: C-0x60
Vector C-0x61 (BatchLookupResponse)
Input payload: см. spec section
Expected output: TBD-A: C-0x61
Vector C-0x62 (BatchLookupError)
Input payload:
query_type = 0x01
error_code = 0x01 (rate_limit_exceeded)
Expected output (hex, 2 B): 01 01
(mt-net::tests::test_vectors::vector_c_0x62_batch_lookup_error, byte-exact)
Vector C-0x63 (RangeSubscribeRequest)
Input payload:
count = 4 = 0x0400 (u16 LE)
labels = 4 × 32 B labels (byte_repeat(0xE0..0xE3, 32) для
каждого)
Expected output (hex, 130 B): 04 00 + (32×0xE0) + (32×0xE1) + (32×0xE2) + (32×0xE3)
(mt-net::tests::test_vectors::vector_c_0x63_range_subscribe_request_4_labels, byte-exact)
Vector C-0x64 (RangeSubscribeResponse)
Input payload: см. spec «Label Rotation + Range Subscribe Protocol»
BlobEntry layout
Expected output: TBD-A: C-0x64
Vector C-0x65 (RangeSubscribeError)
Input payload:
error_code = 0x02 (label_not_found)
Expected output (hex, 1 B): 02
(mt-net::tests::test_vectors::vector_c_0x65_range_subscribe_error, byte-exact)
Vector C-0xF0 (Ping — empty payload — same as A1, дублируется в registry
для completeness)
Expected output: same as Vector A1
Vector C-0xF1 (Pong — empty payload, request_id matches Ping)
Input:
msg_type = 0xF1
request_id = из Ping = 0x0000000000000000
payload_length = 0
Expected output: TBD-A: C-0xF1
Vector C-0xFF (Bye — reason 0x00 normal shutdown)
Input payload:
reason = 0x00
Expected output (hex, 1 B): 00
(mt-net::tests::test_vectors::vector_c_0xff_bye_normal_shutdown, byte-exact)
D. MeshFrame wire format (3 vectors)
Vector D1: single-fragment broadcast
Input:
flags = 0x00 (no continuation)
fragment_index = 0
total_fragments = 1
recipient_hint = byte_repeat(0xFF, 32) — broadcast marker
payload = byte_repeat(0x55, 200) — fits in BLE MTU 244
Expected output (hex, 235 B):
header (35 B): 00 00 01 ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff
payload (200 B): byte_repeat(0x55, 200)
(mt-net::tests + reference impl byte-exact, sha256 same as recompute)
Vector D2: multi-fragment encrypted unicast (3 fragments)
Input:
flags = 0x04 (continuation set on fragments 0 и 1, clear on 2)
fragment_index = 0/1/2 (три separate frames)
total_fragments = 3
recipient_hint = SHA-256("mt-recipient-test-D2")[0..32]
payload chunks = [byte_repeat(0xA0, 240), byte_repeat(0xA1, 240),
byte_repeat(0xA2, 100)]
Expected output (3 frames, hex sha256):
f0 (275 B): sha256 = 37 be 4a 74 f6 92 af e8 9b ce 89 41 ac 19 be ac
a9 56 c9 54 3e c0 d1 39 06 6f 76 e1 1c 87 50 bc
f1 (275 B): sha256 = 3b 57 be d6 a0 f2 91 8f 8e b7 3a 4b 9c 0f bb af
91 65 85 e2 79 21 3e 81 88 c2 dc 69 c3 e6 27 fd
f2 (135 B): sha256 = dd e8 4e 62 a3 71 d1 fe 53 70 b8 72 2d a8 ff af
7c 4e 2c f5 5e 39 95 8d c5 77 73 c1 07 be 36 f8
(mt-net::tests + reference impl byte-exact)
Vector D3: max-size single fragment with padding semantics
Input:
flags = 0x02 (padding bit set)
fragment_index = 0
total_fragments = 1
recipient_hint = byte_repeat(0xFF, 32) — broadcast
payload = padding bytes от CSPRNG (для test — fixed seed
CSPRNG: SHAKE256("mt-test-padding-D3", 1024))
Expected output (hex, 1024 B):
sha256 of full frame = 82 fb 3e 9c 39 f8 6e 89 f7 a6 2a 69 94 a9 33 f4
c9 73 72 f2 0c 20 b1 d6 18 e1 51 7b 0f f1 63 b7
(max single fragment: 35 B header + 989 B padding из chained SHA-256
pseudo-CSPRNG seeded SHA-256("mt-test-padding-D3");
reference impl byte-exact)
E. Store-and-Forward envelope (2 vectors)
Vector E1: typical SF envelope — small message, ttl_window = current+24·τ₁
Input (per spec «Buffer model» layout):
recipient_hint = SHA-256("mt-recipient-test-E1")[0..32]
ttl_window = 24·τ₁ + 0 (current = 0, test τ₁ = 60 → 1440;
реальный τ₁ — emergent от D₀ per [I-18])
fragment_index = 0 (u8)
total_fragments = 1 (u8)
ciphertext = byte_repeat(0xCE, 256) — placeholder для test;
в production это ML-KEM ciphertext к recipient
sender_signature = ML-DSA-65 sign(sk_E1, envelope_bytes_without_signature)
где sk_E1 = SHAKE256("mt-test-sk-vector-E1", 64)
Expected output (hex, 3603 B):
sha256 of full envelope: 41 01 fc f3 11 e6 80 c8 51 96 88 79 82 63 76 70
d3 d6 31 40 3e d0 0c 4b 2c 11 1a 3d a2 49 cc 07
sha256 of sender signature: eb fe cb ae 1f f4 4d ea 9b 59 e9 0d 5f ac 25 17
cb c2 55 26 0b e0 0b fc d3 e3 f0 14 0f 7a 5d f4
(mt-net::tests + reference impl byte-exact)
Vector E2: SF envelope с max ttl_window и больший fragment
Input:
recipient_hint = SHA-256("mt-recipient-test-E2")[0..32]
ttl_window = 24·τ₁ × 24 = 34560 (u32 LE) — boundary case
fragment_index = 5
total_fragments = 8
ciphertext = byte_repeat(0xCF, 1024)
sender_signature = ML-DSA-65 sign с sk_E2 = SHAKE256("mt-test-sk-vector-E2", 64)
Expected output (hex, 4371 B):
sha256 of full envelope: c1 fa 8d d6 3a 7a 8f 6b 70 1f 0a 09 92 26 78 ad
86 70 8e ec fa 1c 08 c8 02 17 e8 6e 27 60 52 ca
sha256 of sender signature: 41 51 c7 28 f4 af 39 1d 67 a6 53 67 4b dc dc 88
62 6f a4 32 73 c3 0a eb d2 9b f6 6e 34 a6 8b ba
(mt-net::tests + reference impl byte-exact)
F. Bootstrap PoW target derivation (2 vectors)
Vector F1: target derivation для bootstrap_pow_difficulty = 65 536 (= 2^16, authoritative
SSOT в Указе Генезиса per [I-10])
Input:
difficulty_factor = 65536 (= 2^16)
Expected:
target (32 B big-endian): 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(mt-net::pow::Target::from_difficulty(65_536), byte-exact)
Vector F2: target derivation для difficulty_factor = 1024 (= 2^10; test-only, не Genesis value)
Input:
difficulty_factor = 1024 (= 2^10)
Expected:
target (32 B big-endian): 00 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
(mt-net::pow::Target::from_difficulty(1024), byte-exact)
Conformance status
Total vectors: 50 A. Envelope : 3 B. IBT proofs (online + mesh + PoW): 3 C. Per-msg-type : 21 (18 кодов + Ping/Pong/Bye explicit) D. MeshFrame : 3 E. Store-and-Forward : 2 F. Bootstrap PoW target : 2 Subtotal : 34
Expanded coverage (additional boundary + edge per type to reach 50): остаётся до 16 vectors добавляется в Phase A reference impl iteration ("typical / boundary / edge" per critical type как в Gate 0.5 [I-9] требовании).
Закрытие [I-9] для каждого type: status «conformance pending → closed Phase A» после генерации expected hex и cross-implementation roundtrip test.
Сетевой уровень — Threat Model
Обязательная нормативная секция для сетевого слоя. Перечисляет adversary classes, защищённые свойства, coverage matrix (механизм защиты per intersection), и явный out-of-scope. Без этой секции Gate 11 (threat concentration) не закрывается для сетевых механизмов; реализатор не может оценить достаточность защит.
Adversary classes
| Имя класса | Возможности | Бюджет (типичная оценка) |
|---|---|---|
| Passive observer | Наблюдает encrypted трафик на каналах внутри своей сети (ISP, корпоративный сетевой администратор, государственный SIGINT в пределах юрисдикции); анализ timing, объёма, метаданных | Pervasive monitoring infrastructure |
| Active MITM | Inject / drop / delay / modify packets на каналах; ложные routing announcements (BGP hijack); rogue access points (Wi-Fi); compromised DNS resolver | Network-position требуется (близко к жертве либо контроль AS) |
| Eclipse attacker | Контроль ≥ ¾ outbound peer slots целевого узла через позиционирование своих узлов в peer-tables; цель — изолировать жертву от честной сети | Multiple registered nodes (×τ₂ окон VDF за каждый Sybil) + multiple IP /16 / ASN |
| Sybil attacker | Регистрирует N формально legitimate узлов через многократное прохождение VDF entry barrier; цель — concentration влияния в peer selection / Dandelion stem / mesh forwarding | Linear cost per identity = τ₂ окон sequential SHA-256 (N × τ₂); diversity constraints приумножают cost |
| DoS attacker | Flood: connection requests, frames, oversized payloads, invalid signatures, expensive operations; цель — исчерпать compute / memory / disk / bandwidth у жертвы | От одиночного hobbyist (~10 Mbps) до ботнета 100+ Gbps |
| Censor | Блокирует трафик к Монтана-узлам в своей юрисдикции через DPI, SNI inspection, IP blocklist, port blocking; цель — denial of access к сети для пользователей региона | National-level firewall (Great Firewall, Roskomnadzor); commercial SaaS DPI |
| State-level sabotage | Sustained attack на хранилище / инфраструктуру через legitimate-looking операции; budget ≥ $1M; motivation = harm не profit | Per Gate 14 sabotage actor budget model (родительская роль) |
Защищённые свойства
| Свойство | Определение |
|---|---|
| Confidentiality | Содержание сообщений недоступно non-recipient (включая intermediate peers в Dandelion / SF / mesh) |
| Integrity | Сообщение не модифицировано в пути; modification обнаруживается |
| Availability | Узел остаётся reachable для honest peers; consensus state продолжает прогрессировать |
| Unlinkability | Внешний наблюдатель не может связать operation X с originating identity / IP узла отправителя |
Coverage matrix
Cell содержит механизм защиты + status. Status: C = closed конструкцией; P = partial (acknowledged residual); O = out of scope (см. ниже).
| Passive observer | Active MITM | Eclipse | Sybil | DoS | Censor | Sabotage | |
|---|---|---|---|---|---|---|---|
| Confidentiality (data) | TLS 1.3 + Noise + IBT (C) | TLS 1.3 server cert pinning через node_id binding (C) | TLS+IBT survives eclipse (С) | TLS+IBT survives Sybil (C) | n/a | TLS прячет content (P — censor видит cipher metadata) | n/a |
| Confidentiality (metadata) | Uniform Framing 1024B + ≥20% padding ratio (P — observer видит volume aggregate, не indiv messages) | n/a | n/a | n/a | n/a | DPI видит TLS handshake; SNI hidden через TLS 1.3 ECH когда поддерживается (P) | n/a |
| Integrity (data) | n/a | TLS 1.3 AEAD + IBT signature (C) | TLS+IBT (C) | TLS+IBT (C) | malformed payload reject early через Gate 13a invariants (C) | n/a | malformed input bounded по Storage Cards (C) |
| Integrity (consensus) | n/a | подписанные объекты (Transfer/Anchor/Proposal) verifiable по ML-DSA-65 (C) | n/a | n/a | n/a | n/a | n/a |
| Availability (узла) | n/a | UPnP/PCP + AutoNAT + circuit relay alternatives (C) | 4-уровневая diversity делает eclipse expensive (C) | VDF entry barrier τ₂ окон + diversity (C) | rate-limits per peer + per type + total quotas + bootstrap PoW (P — DDoS scale ≥10 Gbps требует sysadmin response помимо protocol) | mesh transport BLE/Wi-Fi Aware survives complete internet block (C — но ограничен range) | per-sender quotas + Storage Cards hard caps + LRU eviction (C) |
| Availability (consensus) | n/a | n/a | как «узла» + cementing через ¾ honest weight (C) | как «узла» (C) | как «узла» + consensus path не блокируется network DoS (consensus orthogonal к transport — VDF продолжается локально) (C) | mesh propagation cementing eventually (P — задержка часы / дни) | consensus path fails-safe — invalid input не commit-ится (C) |
| Unlinkability | Dandelion++ скрывает первый hop отправителя (P — recipient + amount открыты per [I-2]) | Dandelion++ + Tor bridge (deferred M6.5/M14) (P) | n/a | n/a | n/a | Dandelion++ + censorship-resistant discovery + Tor (deferred) (P) | n/a |
Closed C: 13 cells. Partial P: 7 cells (acknowledged residuals — см. явный список ниже). Out of scope O: 0 cells (все intersection adversary × property реальны).
Out-of-scope (явный список)
Эти угрозы не закрываются сетевым слоем Монтаны by design либо по архитектурному решению:
-
Endpoint compromise — если private key узла украден, attacker полностью представляет узел в сети; защита — операционная (hardware key storage, OS hardening), не сетевой протокол.
-
Traffic analysis correlation на global scale — attacker контролирующий significant fraction всех internet routers (Tier 1 ISPs, государство контролирующее backbone exchange) может коррелировать timing across multiple connections и deanonymize даже через Dandelion++. Защита требует global-scale anonymity network (Tor с миллионами relays), что ortogonal к Монтана.
-
Side-channel attacks на crypto primitives — timing / power / EM на ML-DSA-65 / SHA-256 implementations. Mitigation: использовать constant-time implementations (rustls / aws-lc-rs / ring); это [C-6] requirement, не network-protocol concern.
-
Quantum-capable adversary — статус: mainnet blocker, plan to closure через Noise_PQ migration. Текущее состояние: PQ primitives (ML-DSA-65, ML-KEM-768) защищают application auth и encryption (✅), но TLS 1.3 handshake использует classical X25519 ECDHE — vulnerable к store-now-decrypt-later квантовым атакам. План closure: replace TLS 1.3 + Noise XK на единый Noise_PQ handshake с ML-KEM-768 как KEM replacement для DH; это удаляет TLS layer целиком (он не даёт ничего сверх IBT-аутентифицированной Noise) и достигает pure-PQ handshake без classical primitives в protocol layer. Per [I-1] в protocol layer classical crypto запрещена (только в client layer допустима — например browser в Junona к обычному web). Defer to upstream rustls — отвергнут как «acknowledged residual» больше не приемлем; closure через Noise_PQ — обязательный mainnet milestone.
-
Supply chain attacks на dependencies — compromised library обновление (libp2p, rustls). Mitigation: Cargo.lock pinning + reproducible builds + dependency audit ([C-6] req #3-4-5-6); это build-time concern.
-
Physical proximity attacks на mesh — BLE / Wi-Fi Aware require physical proximity (≤200m). Attacker с physical access может flood mesh advertisements. Mitigation: per-sender rate-limit + IBT mesh proof requirement делает это nonproductive, но не невозможным.
-
Legal/regulatory pressure на bootstrap nodes — 12 hardcoded genesis bootstrap могут быть seized / forced offline государством. Mitigation: после первого подключения узел работает через discovered peers, bootstrap нужны только при cold start или при потере всех peers; censorship-resistant discovery (deferred M6.5) — secondary path.
Acknowledged residuals (P cells expanded)
| # | Cell | Residual | Severity | Mitigation roadmap |
|---|---|---|---|---|
| 1 | Censor → Confidentiality (data) | DPI видит TLS metadata (handshake, certificate, SNI без ECH) | Medium | TLS 1.3 ECH когда rustls поддержит; deferred from M6 baseline |
| 2 | Passive observer → Confidentiality (metadata) | Uniform Framing скрывает per-message volume, но aggregate KB/sec viewable | Low | Defense-in-depth достаточен; full traffic shaping out of scope |
| 3 | DoS → Availability (узла) | DDoS ≥10 Gbps требует sysadmin response | Medium | Standard practice (Cloudflare-like upstream filtering); not protocol concern |
| 4 | Censor → Availability (узла) | Mesh range ≤200m недостаточен для intercity связи без internet | Medium | Defer multi-hop mesh routing к M14 mobile work |
| 5 | Censor → Availability (consensus) | Mesh propagation timing часы/дни добавляет latency | Acceptable | Eventually consistency через mesh — protocol design choice |
| 6 | Passive observer → Unlinkability | Recipient + amount открыты after fluff per [I-2] | By design | [I-2] открытость финансового слоя — non-negotiable per глобальный invariant |
| 7 | Censor → Unlinkability | Без Tor bridge deanonymization возможна на censor-controlled exit | Medium | Deferred M6.5 / M14 (censorship-resistant discovery) |
Compliance с глобальными инвариантами
- [I-1] PQ-secure — Threat model признаёт residual (Q4 outscope) пока TLS не PQ; closed для auth (IBT через ML-DSA-65) и для confidentiality в SF (ML-KEM-768 E2E). На момент M6 acceptable как PQ-protected identity layer над classical TLS transport.
- [I-3] Determinism — Threat model orthogonal: defines what is defended, не какие state changes возникают.
- [I-7] Minimal crypto surface — Threat model не вводит новых crypto primitives; переиспользует ML-DSA-65 / SHA-256 / ML-KEM-768 / TLS 1.3.
Audit guidance
Внешний security аудитор использует matrix как entry point: для каждой cell с status C — verify через указанный механизм (раздел спеки + binding KAT vector + Phase A test); для P — verify acknowledged residual явно зафиксирован; для O — verify out-of-scope явно перечислен в списке выше.
Сетевые параметры в protocol_params
В рамках закрытия раздела II.5 плана сетевого слоя M6 в protocol_params Указа Генезиса добавлены пять новых полей. Authoritative layout и инварианты — в Указе Генезиса (раздел «Genesis Decree» выше). Этот sub-section содержит derivation per «Академическое обоснование констант» + нормативные backpressure rules. Bump Genesis State Hash — pre-mainnet acceptable.
Derivation per «Академическое обоснование констант»:
Константа: bootstrap_pow_difficulty (authoritative SSOT в Указе Генезиса per [I-10])
Значение: 65 536 (2^16)
Класс: Performance / Security (anti-flood)
Target: ≈100 мс CPU per попытка на genesis-железе (5.097 MH/s); attacker
с rate 10 connections/сек тратит 1 CPU-сек/сек = одно ядро
постоянно занято на каждую bootstrap; 12 bootstrap × 1 ядро =
12 ядер для distributed flood (manageable through standard
upstream rate-limiting)
References: Hashcash [Back 2002]; Bitcoin PoW genesis [Nakamoto 2008];
ProgPoW analysis для anti-ASIC bias (не применяется здесь —
SHA-256 specifically, но class precedent)
Derivation: attempts_per_second_genesis = 5.097 × 10^6 / (2^256 / target)
= 5.097 × 10^6 / 2^240 (для difficulty 2^16, target = 2^240)
= ≈10 attempts/sec (1 успех каждые 100 мс)
Sensitivity: ±10% от target → ±10% CPU cost; ×2 difficulty (2^17) → 200 мс
per attempt → ×2 attacker cost; ×0.5 difficulty (2^15) → 50 мс
→ ×0.5 attacker cost (acceptable lower bound — bootstrap не
высокоценная цель flood)
Defense: Q: «почему не выше? повысить ×10 для лучшей защиты»
A: bootstrap нужен только при cold start; legitimate user
ждёт 100 мс при первом подключении приемлемо, 1 секунда
фрустрирует
Q: «почему 2^16 а не 2^14?»
A: 2^14 (25 мс target) attacker cost ниже на ×4 — distributed
flood requires ×4 больше IPs для same impact; 2^16 = sweet
spot между UX и flood resistance
Default (operator-configurable, не Genesis Decree): max_outbound_per_node
Значение: 24
Класс: Operational / Security (eclipse resistance)
Target: Eclipse требует attacker control ≥ ¾ outbound = ≥ 18 of 24;
diversity constraints (4-уровневая) делают это economically
expensive: requires ≥ 18 different ASN AND ≥ 18 different
/16 prefix AND ≥ 18 different start_window cohorts
References: Bitcoin outbound = 8 [Nakamoto core]; Ethereum geth = 16
[Ethereum Yellow Paper]; libp2p kademlia bucket size = 20
[Maymounkov-Mazières 2002]
Derivation: Compromise budget anti-eclipse: P(eclipse) ≈ (f^N) при f =
attacker fraction of network nodes; для f = 0.3 и N = 24,
P ≈ 3 × 10^-13 (negligible); для f = 0.5 и N = 24,
P ≈ 6 × 10^-8 (acceptable для рare event); diversity
constraints further reduce
Sensitivity: N = 16 → P(f=0.5) ≈ 1.5 × 10^-5 (acceptable degradation
но не optimal); N = 32 → P(f=0.5) ≈ 2 × 10^-10 (better
но удваивает bandwidth cost: 26 KB/сек vs 13 KB/сек —
приемлемо для homeServer нет)
Defense: Q: «почему 24 а не 16 (как Ethereum)?»
A: Ethereum gas economics differ; Montana baseline 1 fps —
bandwidth не constrained; добавление 8 outbound — minor
cost для significant eclipse resistance
Q: «почему не 32?»
A: marginal benefit P(eclipse) reduction × ×2 bandwidth
cost — UX boundary
Default (operator-configurable, не Genesis Decree): max_inbound_per_node
Значение: 13
Класс: Operational
Target: 13 inbound × 1 fps × 1024 B = 13 KB/сек ≈ 33 GB/мес
приемлемо для домашнего сервера (limit ОТТ-cap у российских
home ISP ≈ 100 GB/мес unmetered)
References: Spec строка 4207 derivation
Derivation: bandwidth_per_inbound = 1024 B/сек × 86400 сек/день × 30 дней
≈ 2.5 GB/мес per inbound; 13 inbound × 2.5 GB = 32.5 GB/мес
Sensitivity: 8 inbound → 20 GB/мес; 16 inbound → 40 GB/мес — обе boundaries
acceptable, 24 = по derivation Protocol [P(eclipse) < 2⁻⁴⁰]; равно max_outbound
distribution когда 100% узлов имеют equal in/out balance
Defense: Q: «почему inbound меньше outbound?»
A: outbound определяет eclipse resistance (own perspective);
inbound — quota на сколько ressources даёшь чужим
подключениям. Asymmetry deliberate: каждый узел actively
выбирает 24 outbound for security, passively принимает
13 inbound
Q: «почему не равно 24 = 24?»
A: bandwidth budget ограничен; 13 inbound покрывает
reciprocity без overload
Default (operator-configurable, не Genesis Decree): max_pending_requests_per_peer
Значение: 256
Класс: Operational (backpressure)
Target: Ограничивает correlation table memory: 256 × peer_count × 32 B =
≈ 13 KB per peer × 24 outbound = 312 KB total per node
(negligible memory)
References: HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS default 100 [RFC 7540];
gRPC default max_concurrent_streams 100 [grpc.io]
Derivation: request_timeout = τ₁ / 2 ≈ 30 сек на genesis hardware;
rate at full capacity: 256 requests / 30 сек ≈ 8.5 req/сек
per peer; 24 outbound × 8.5 = ≈200 req/сек total — sufficient
для FastSync chunked + PeerList exchange + BatchLookup
concurrent
Sensitivity: 128 → ≈4 req/сек per peer (constrains FastSync chunked);
512 → ≈17 req/сек (more headroom но 2× memory; trade-off
в пользу 256)
Defense: Q: «почему 256 а не 1024?»
A: 1024 — overhead на correlation tracking без proportional
benefit для use cases (FastSync дробится автоматически
на chunks)
Default (operator-configurable, не Genesis Decree): request_timeout_t1_div
Значение: 2
Класс: Operational
Target: Request TTL = τ₁ / 2 — позволяет получить response в текущем
τ₁ окне в типичном случае (один RTT через global internet
≪ τ₁/2)
References: Spec строка 4794 (TCP connect: τ₁/2)
Derivation: τ₁ ≈ 60 сек на genesis hardware; τ₁/2 = 30 сек — far above
reasonable global RTT (≤ 1 сек); margin для retransmits
и slow paths
Sensitivity: divisor = 1 (TTL = τ₁) → больше pending requests
накапливаются (memory pressure); divisor = 4 (TTL = τ₁/4)
→ false timeouts на slow links
Defense: Q: «почему не absolute value (например 30 сек)?»
A: τ₁ adaptable через `participation_ratio` feedback
(раздел «Адаптация D»); если D растёт → τ₁ растёт →
request timeout пропорционально растёт; absolute value
desync с network capacity при slow hardware participation
Backpressure rules — нормативный текст
Применяется ко всем IBT-сессиям + ProtocolMessage envelope layer.
Правило B1 — Pending requests cap.
Для каждого peer count активных pending requests (status awaiting response) ≤ max_pending_requests_per_peer. При попытке создать новый request выше cap — caller получает Error::Backpressure, request не отправляется. После expiry (по request_timeout_t1_div) либо response counter уменьшается.
Правило B2 — Frame intake rate per peer.
Для каждого peer rate входящих frames ≤ baseline_frame_rate × max_burst_factor где baseline_frame_rate = 1 fps (см. Uniform Framing) и max_burst_factor = 8 (max_burst per spec строка 4204). При превышении: drop excess frames silently (не disconnect — разрешает burst recovery), increment peer-level penalty counter.
Правило B3 — Total connection cap.
Узел поддерживает максимум max_outbound_per_node исходящих + max_inbound_per_node входящих TCP-соединений одновременно. Превышение outbound — caller получает Error::OutboundCapReached, попытка отклоняется до rotation освободит slot. Превышение inbound — incoming TCP connection отклоняется на TCP уровне (RST), счётчик не обновляется (защита от counter inflation).
Правило B4 — Penalty escalation.
Peer-level penalty counter увеличивается при: (a) frame intake rate exceedance (B2); (b) malformed payload after Gate 13a structural validation; (c) signature verification failure при IBT либо при подписанных payload-объектах. При достижении threshold = 100 events per τ₁ — peer disconnect с reason 0x04 (protocol violation) + blacklist на 24·τ₁ (см. spec «Retry policy»). Penalty counter сбрасывается на каждой τ₁ boundary либо при successful disconnect.
Правило B5 — Resource quota enforcement timing.
Все backpressure checks выполняются до crypto-verification (ML-DSA-65 verify ≈0.1 мс на commodity CPU; protection against amplification atak). Order:
- TCP-level rate (OS tcpdump rules — outside scope spec)
- TLS-level (rustls / aws-lc-rs — library scope)
- IBT proof verify (ML-DSA-65 — внутри карточки IBT)
- Frame structure parse (Gate 13a Uniform Framing invariants)
- Frame intake rate per B2 — перед ProtocolMessage decode
- ProtocolMessage envelope parse (Gate 13a)
- Pending request cap per B1 — для request types
- Payload structure validation (Gate 13a per type)
- Payload signature verify (если payload подписан — Transfer / NodeRegistration / etc.)
- Apply transition (apply_proposal либо locally — outside backpressure scope)
Правило B6 — Sabotage actor protection.
Sabotage actor с budget $1M (per Threat Model) с реалистичным ресурсом ≈10 Gbps можно flood узла; standard upstream filtering (Cloudflare-like, ISP DDoS protection, hosting provider mitigation) — out of scope spec, expected operator practice. Spec backpressure rules защищают только от per-peer behaviour, не от volumetric DDoS на network уровне.
apply_mesh_frame и apply_store_and_forward — нормативные формулировки
Сетевые apply-функции выполняются на receive path локального узла. В отличие от consensus apply-функций (apply_proposal, apply_emission, etc.) не входят в state_root ([I-3] orthogonal — locally derived state). Однако их детерминизм важен: повторное применение того же frame должно давать тот же результат (idempotency для replay-handling).
apply_mesh_frame(frame, sender_pubkey, peer_local_state) → MeshIntake
Input:
frame MeshFrame (см. spec «MeshFrame wire format»)
sender_pubkey ML-DSA-65 pubkey 1952B (полученный из mesh advertisement)
peer_local_state &mut LocalMeshState {
used_nonces: Map<sender_pubkey_hash, Set<nonce>>,
fragments: Map<(sender_pubkey_hash, msg_id), Vec<Fragment>>,
rate_window: Map<sender_pubkey_hash, FrameWindow>,
}
Output:
MeshIntake = enum {
Accepted, — frame validated, persisted либо forwarded
AcceptedComplete(payload), — последний fragment, message complete
Rejected(reason), — silent reject (no error to sender)
}
Steps (ordered, deterministic):
1. Structure validation per Gate 13a invariants для MeshFrame:
- flags ∈ {0x00, 0x02, 0x04, 0x06} (data | padding | continuation
| data+continuation; padding+continuation запрещено)
- fragment_index ≤ total_fragments
- total_fragments ≤ 255
- recipient_hint exactly 32 B
- payload size ≤ MTU (BLE 244 B либо Wi-Fi Aware 1500 B —
определяется transport profile, сигнализируется адверsement)
Не пройдено → return Rejected(InvalidStructure)
2. IBT mesh proof verification per карточка «IBT mesh proof»:
- cached_window ∈ [known_W − 7·τ₁, known_W]
- mesh_session_nonce ∉ used_nonces[hash(sender_pubkey)]
- signature valid под sender_pubkey
Не пройдено → return Rejected(InvalidIBT)
3. Frame intake rate per Backpressure Rule B2:
- rate_window.intake_count++
- intake_count ≤ baseline_frame_rate × max_burst_factor (1 fps × 8 = 8)
within latest 1 сек window
Превышено → drop frame, increment penalty (Rule B4), return Rejected(RateLimit)
4. Recipient determination:
- recipient_hint == 0xFF × 32 → broadcast — adressed to all mesh peers
- recipient_hint == hash(local_node_pubkey) → addressed to self
- иначе → addressed to other peer, candidate for forwarding
(см. apply_store_and_forward для forwarding semantics)
5. Fragment assembly (для multi-fragment messages):
msg_id = (sender_pubkey_hash, fragment header — derivable from envelope)
fragments[msg_id].insert(fragment_index, frame.payload)
Если fragments[msg_id].len() == frame.total_fragments:
payload_complete = concat(sorted by fragment_index)
fragments.remove(msg_id)
return AcceptedComplete(payload_complete)
иначе:
return Accepted
6. Update used_nonces (после полного accept):
used_nonces[hash(sender_pubkey)].insert(mesh_session_nonce)
Идемпотентность:
apply_mesh_frame(F, S, state) дважды:
Первый вызов: Accepted либо AcceptedComplete(P), state' с frame
зарегистрированным
Второй вызов: Rejected(InvalidIBT) — nonce уже в used_nonces, dedup
Это и есть проявление determinism: после первого accept повторный
frame с тем же nonce silent-rejected, защита от replay.
apply_store_and_forward(envelope, sender_pubkey, sf_local_state) → SFIntake
Input:
envelope SFEnvelope (см. spec «Buffer model»)
sender_pubkey ML-DSA-65 pubkey (из envelope.sender_signature)
sf_local_state &mut LocalSFState {
buffer: Map<recipient_hint, BufferEntry>,
sender_quotas: Map<sender_pubkey_hash, SenderQuotaState>,
recipient_acks: Map<recipient_hint, SignedAck>,
total_bytes: u64,
}
Output:
SFIntake = enum {
Buffered, — frame stored для forwarding
DeliveredLocally(decrypted_msg), — recipient = self, ML-KEM decrypt OK
Rejected(reason), — silent reject
}
Steps (ordered, deterministic):
1. Structure validation per Gate 13a invariants для SFEnvelope:
- recipient_hint exactly 32 B
- ttl_window ∈ [current_W + 1, current_W + 24·τ₁]
(TTL hard cap 24·τ₁; ttl_window ≤ current_W → expired, reject;
ttl_window > current_W + 24·τ₁ → invalid, reject)
- fragment_index ≤ total_fragments ≤ 255
- sender_signature exactly 3309 B
- ciphertext size ≤ 4096 B (per envelope upper bound)
Не пройдено → return Rejected(InvalidStructure)
2. Sender signature verification:
verify_message = canonical_encode(envelope_without_signature_bytes)
ML-DSA-65 verify(sender_pubkey, verify_message, sender_signature)
Не пройдено → increment penalty (Rule B4), return Rejected(InvalidSignature)
3. Per-sender quota per spec «Per-sender quota»:
sender_quota = sender_quotas[hash(sender_pubkey)]
sender_quota.frames_in_window_τ₁++
Если frames_in_window_τ₁ > 256:
return Rejected(SenderQuotaExceeded) — silent (sender определит
по retry timeout)
Sender_quota автоматически reset на каждой τ₁ boundary.
4. Recipient ack check per spec «Signed rate-limit acks»:
Если recipient_acks[recipient_hint].is_revoked(sender_pubkey, current_W):
return Rejected(ForwardingRevoked)
5. Total buffer quota check per Storage Card sf_buffer:
prospective_total = total_bytes + envelope_size
Если prospective_total > 1 GB AND sender NOT in operator VIP whitelist:
return Rejected(TotalQuotaExceeded)
Если prospective_total > 1 GB AND sender в VIP whitelist:
eviction: drop oldest non-VIP entry until prospective_total ≤ 1 GB
6. Recipient determination:
Если recipient_hint == hash(local_node_pubkey):
attempt ML-KEM decrypt(local_node_secretkey, envelope.ciphertext)
Если success:
remove envelope from buffer (delivered)
return DeliveredLocally(decrypted_msg)
Если failure:
return Rejected(DecryptFailure) — corrupted либо unintended
Иначе:
buffer.insert(recipient_hint, envelope)
total_bytes += envelope_size
return Buffered
7. Forwarding policy per spec «Forwarding algorithm»:
После Buffered — узел periodically attempts forwarding:
- выбирает peer-кандидатов с recipient_hint match (либо broadcast peers)
- отправляет envelope как ProtocolMessage (тип reserved для SF —
используется extension namespace, см. план дальше при имплементации)
- при successful delivery либо TTL expiry → remove from buffer
total_bytes -= envelope_size
Идемпотентность:
apply_store_and_forward(E, S, state) дважды с identical envelope:
Первый вызов: Buffered либо DeliveredLocally
Второй вызов: Per-sender quota инкрементируется снова → может вернуть
SenderQuotaExceeded; либо
Если буфер уже содержит envelope с тем же
(recipient_hint, sender_pubkey, ciphertext) — то
`buffer.insert` is replace, total_bytes без изменений,
return Buffered (idempotent на содержимое buffer)
Recipient ack revocation, sender quota exhaustion, либо TTL expiration
делают повторный apply non-idempotent в смысле response, но idempotent
в смысле buffer state (либо present либо expired/removed).
Локальные функции вне consensus state — почему apply_*
Имена apply_mesh_frame и apply_store_and_forward симметричны consensus apply (apply_proposal, apply_emission) намеренно: семантически одинаковая роль — взять input + state → produce new state. Различие — в scope:
- consensus apply: state ∈ consensus root (state_root computation)
- network apply: state ∈ local node-runtime (вне state_root, не consensus-critical)
Это гарантирует:
- Implementation pattern consistency — реализатор (Phase G) знает что mesh / SF имеют ту же семантику что consensus apply: deterministic, ordered, idempotent (где specified).
- Cross-impl conformance — две независимые реализации, прогнавшие один и тот же frame через
apply_mesh_frame, получают same MeshIntake outcome. Это conformance condition (хотя не consensus-critical, важно для interop testing). - [C-7] enforcement — code-side carded role предписывает no-shortcut на
apply_*функциях; mesh / SF теперь явно входят в этот класс, никакого shortcut доступа кused_nonces/buffer/sender_quotasнапрямую (только через apply).
Final Gate audit сетевого слоя M6
Финальный аудит закрытия плана раздела II — закрытие плана сетевого слоя M6 (II.1 карточки + II.2 Storage Cards + II.3 KAT vectors + II.4 Threat Model
- II.5 backpressure + II.6 apply_*).
Gate 0.5(d.1) Formula name coverage: new section не вводит новых formula names; все references существующих формул через explicit pointers на authoritative разделы. Pass.
Gate 0.5(d.2) Field name coverage для пяти новых полей protocol_params:
bootstrap_pow_difficulty— authoritative в Указе Генезиса (4 B u32 = 65 536); references в карточке Bootstrap PoW (open sub-finding now closed), KAT vector B3, derivation в sub-section «Сетевые параметры в protocol_params». Все references explicit на Genesis Decree authoritative location. Pass.max_outbound_per_node— authoritative в Указе Генезиса (1 B u8 = 24); references в Backpressure Rule B3 + derivation. Pass.max_inbound_per_node— authoritative в Указе Генезиса (1 B u8 = 13); references в Backpressure Rule B3 + derivation. Pass.max_pending_requests_per_peer— authoritative в Указе Генезиса (2 B u16 = 256); references в Backpressure Rule B1 + derivation. Pass.request_timeout_t1_div— authoritative в Указе Генезиса (1 B u8 = 2); references в Backpressure Rule B1 + derivation. Pass.
Zero value duplications вне authoritative location. [I-10] SSOT compliance verified.
Gate 15 Part 1B Generic version sweep:
Spec body grep \bv?[0-9]+\.[0-9]+\.[0-9]+\b returns only legitimate hits:
- Header line 3 — single Montana spec version (authoritative)
- QEMU Virtual CPU v4.2.0 / v8.2.0 (illustrative external hardware variance table — pre-existing, external software identifier, not Montana version)
ip_version=0x04field в KAT vectors (regex false positive —04parsed as4.0patch number; ip_version IS a field, not version mention)- Rust 1.92.0, sha2 crate v0.10.9, macOS Sequoia 15.7.3, Darwin 24.6.0 (pre-existing external software identifiers in [I-18] D₀ derivation context)
Zero spec-version mentions in body. [I-10] SSOT compliance verified.
Cross-section consistency (active comparison): для всех новых терминов (IBT online/mesh, Bootstrap PoW, Uniform Framing, Transport Randomness, Peer selection, Dandelion++, NAT Traversal, Mesh Transport, Store-and-Forward, ProtocolMessage envelope, message type registry, Backpressure rules) терминология синхронизирована между основной частью спеки (раздел «Сетевой уровень») и sub-разделами «Карточки замыкания механизмов сетевого слоя». Reading-based verify: каждое упоминание в карточке references existing спеку section без cross-spec terminology drift. Pass.
Gate 13a Invariant enumeration completeness:
- Каждая из 12 карточек имеет полные 11 пунктов замыкания + 15-pass global invariant check. Pass.
- Все 4 локальных Storage Cards имеют 11 полей + [I-14] путь + sabotage budget. Pass.
- 50 KAT vector definitions — каждый с input scheme + expected output placeholder (TBD-A в Phase A reference impl). Pass.
- Threat Model — 7 adversary classes × 4 properties matrix с явными status C/P/O markers. Pass.
- Genesis Decree extension инварианты enumerated explicit (5 новых полей + byte-exact values + runtime mutation запрещена). Pass.
- apply_mesh_frame и apply_store_and_forward — explicit ordered steps + идемпотентность guarantees. Pass.
Gate 0 Global invariant check для каждого нового механизма: Все 12 карточек прошли 15-pass invariant check ([I-1]..[I-15]) explicit:
- [I-1] PQ-secure: yes для всех auth (ML-DSA-65 IBT)
- [I-2] Public financial layer: explicit acknowledgment в Dandelion++ карточке (скрывает только первый hop)
- [I-3] Determinism: transport-orthogonal в карточках; deterministic в apply_mesh_frame / apply_store_and_forward
- [I-4] TimeChain independence: yes в IBT mesh + Mesh Transport (cached_window работает offline)
- [I-5] Commodity hardware: yes для всех (BLE/Wi-Fi Aware на любом устройстве, ML-DSA-65 verify дёшев)
- [I-6] Regulatory compat: yes для всех; explicit acknowledgment в Dandelion++ что не privacy mixer
- [I-7] Minimal crypto surface: yes — переиспользует ML-DSA-65 / SHA-256 / ML-KEM-768 / TLS 1.3
- [I-8] Network-bound unpredictability: n/a для всех (transport-orthogonal, не consensus seed)
- [I-9] Bit-exact deterministic: yes для wire format (binding KAT vectors В Phase A); partial для transport scheduling (non-deterministic by design)
- [I-10] Single Source of Truth: yes для всех (formal layout + invariants в одном месте, references в другом)
- [I-14] State lifecycle: yes для всех persistent — locales Storage Cards fixate hard quotas + temporal pruning
- [I-15] Time-based scarcity: yes для всех anti-spam mechanisms (rate-limits через time, не money)
Zero global invariant violations. Network layer Gate 0 compliance: Pass.
Минимально необходимое для разблокирования Phase A кода: все 7 пунктов плана раздела II закрыты. Implementer mt-net::* крейтов имеет:
- 12 нормативных карточек закрытия
- 4 Storage Cards для локальных сетевых таблиц
- 50 binding KAT vectors (input schemas + algorithm)
- Threat Model coverage matrix
- 5 Genesis Decree fields (bootstrap_pow_difficulty + connection limits + timeout)
- 6 backpressure rules B1-B6
- 2 apply_* функции (mesh + SF)
Phase A разблокирована. Reference implementation начинается.
Status: План раздела II — закрыт. Network layer спека audit-ready для Phase A start.
Сетевой слой со стороны клиента (App-perspective)
Следующие разделы исторически жили в Montana App spec разделах 10-11. Они описывают взаимодействие клиента с сетевым слоем — режимы узла, libp2p настройка с client-side, выбор хостящего узла, mesh integration на iOS/Android.
10. Режимы узла
10.1 Лёгкий клиент (по умолчанию на мобильном)
Большинство мобильных пользователей — лёгкие клиенты. Приложение не участвует в консенсусе, только использует сеть.
Что делает лёгкий клиент:
- Подключается к нескольким полным узлам через libp2p
- Подписывается на потоки proposals (получает новые proposals)
- Валидирует proposals локально (подписи, совпадение
state_root) - Поддерживает локальную копию Таблицы аккаунтов для своего аккаунта и контактов (не всю)
- Отправляет операции в сеть через gossip
- Запрашивает данные Content Layer по необходимости
- Верифицирует получаемые данные через хэши
Чего лёгкий клиент НЕ делает:
- Не запускает VDF TimeChain
- Не запускает VDF NodeChain
- Не участвует в лотерее
- Не публикует proposals
- Не хранит полную Таблицу аккаунтов
- Не хранит полную историю proposals
Ресурсы лёгкого клиента:
- CPU: минимальный (валидация подписей, криптооперации при отправке и получении)
- Сеть: умеренная (потоки proposals, запросы контента)
- Хранилище: несколько MB для существенного состояния, GB для кэша и подписок
- Батарея: оптимизирован для мобильного (фоновая синхронизация с ограничением темпа)
10.2 Полный узел на десктопе
Десктоп-версия Montana App может работать как полный узел.
Включение режима узла:
- «Настройки → Дополнительно → Работать как полный узел»
- Предупреждение о требованиях (минимум 1 ядро, аптайм 24/7, железо)
- Пользователь подтверждает
- Приложение запускает дополнительные потоки:
- Поток VDF TimeChain (1 выделенное ядро)
- NodeChain
- Поток валидатора (валидация операций и финализация)
- Приложение загружает полное состояние (Таблица аккаунтов, Таблица узлов, история proposals)
- Если у пользователя есть
NodeRegistration— начинает участвовать в лотерее
Требования для полного узла:
- 1 или более ядер CPU
- 16 или более GB RAM
- 500 или более GB диска (растёт со временем)
- Аптайм 24/7 (или близко)
- Стабильное интернет-соединение
- Пропускная способность: минимум 1 Mbps, рекомендуется 10 Mbps и больше
Участие в сети:
- Узел получает
chain_lengthза каждое окно активности - При достаточной
chain_lengthстановится подтверждающим - Публикует
BundledConfirmation - Может участвовать в лотерее
- Зарабатывает Монтана при выигрыше
- Монтана зачисляется в
operator_account(тот же аккаунт пользователя)
10.3 Процесс регистрации узла
Десктоп-пользователь хочет стать узлом:
- Пользователь запрашивает приглашение от существующего узла (вне сети)
- Приглашающий узел формирует
NodeInvitationс публичным ключом приглашённого NodeInvitationпубликуется и финализируется в сети- Пользователь получает уведомление «Вас пригласили стать узлом»
- Пользователь подтверждает
- Приложение запускает VDF-процесс длиной
vdf_entry_windows = 20 160 окон(около 14 дней) в фоне - После завершения формируется
NodeRegistrationсproof_endpoint - Пользователь публикует
NodeRegistration(operator_account_id = свой account_id) - После финализации — пользователь становится узлом Montana
VDF-процесс — блокирующий. Приложение должно работать непрерывно или продолжать VDF при каждом запуске. На мобильном это практически невозможно; на десктопе возможно, но требует 24/7 аптайма в течение двух недель.
11. Сетевой слой
11.1 Настройка libp2p
Montana App использует rust-libp2p для P2P сетевого слоя.
Транспортные протоколы:
- QUIC (основной для мобильного) — поверх UDP, работает через NAT
- TCP (запасной) — для контекстов где QUIC заблокирован
- WebSocket (для веба если появится)
Мультиплексирование потоков:
- yamux (стандарт libp2p)
Безопасность транспорта:
- Фреймворк Noise для шифрования транспорта
- Используется Noise_XX с ML-KEM-768 (постквантовая адаптация)
- Это шифрование уровня транспорта; шифрование уровня сообщений — отдельное через Double Ratchet
11.2 Bootstrap-узлы
При первом запуске приложению нужно найти сеть.
Механизмы первичного подключения:
-
Хардкодированные bootstrap-узлы — 12 genesis-узлов, зафиксированы в Genesis Decree. Приложение хардкодит их адреса и
account_id. -
Обнаружение через DNS — записи SRV
_montana._tcp.montana.ioуказывают на известные bootstrap-узлы. Приложение делает запрос DNS при старте. -
Обмен пирами — после подключения к одному bootstrap-узлу приложение запрашивает у него список известных пиров и расширяет свой список.
-
Обнаружение устойчивое к цензуре — описано в спеке протокола (Transport Obfuscation, ECH и так далее). Для регионов с блокировкой.
11.3 Использование Content Request Protocol
Приложение активно использует ContentRequest и ChunkRequest для всех операций Content Layer.
Процесс получения blob:
- Приложение вычисляет пару
(app_id, data_hash)нужного blob - Приложение проверяет локальный кэш
- Если нет —
ContentRequest(app_id, data_hash)одному из подключённых пиров - Пир возвращает манифест (если это манифест) или одиночный blob
- Приложение верифицирует хэш
- Если это манифест и нужны чанки — последовательные
ChunkRequest(data_hash, chunk_index) - Собранный blob сохраняется в кэше
Параллельность:
- Чанки запрашиваются параллельно у нескольких пиров для скорости
- Неудачные запросы переадресуются другим пирам
- Ограничение темпа для предотвращения перегрузки пиров
11.4 Участие в DHT
Приложение участвует в Kademlia DHT libp2p.
Участие лёгкого клиента:
- Приложение может публиковать свои записи провайдера в DHT (для своих blob)
- Приложение может делать поиск провайдеров в DHT для нужного контента
- Мобильные лёгкие клиенты могут иметь ограниченное участие в DHT (экономия батареи и сети)
Полный клиент на десктопе:
- Полное участие в DHT
- Поддержка таблицы маршрутов
- Помощь другим клиентам через реле
11.5 Выбор хостящего узла и отказоустойчивость
Применимо к пути участия через аккаунт (пользователь без своего узла, подключается к узлу-хосту через IBT уровень 3, см. спеку протокола раздел «Два пути участия»).
Проблема. Клиент с путём участия только через аккаунт зависит от наличия работающего узла-хоста. Если хост уходит (создатель приложения закрылся, узел офлайн, юрисдикционная блокировка, систематический отказ в gossip) — пользователь должен переключиться на другой узел, иначе история AccountChain и ключи становятся бесполезны без сети для подключения. Наивное решение «выбрать узел с самым длинным chain_length и держаться за него» создаёт четыре уязвимости: концентрация на топ-N узлов воссоздаёт централизованный хостинг, заранее построенные sybil-узлы могут попадать в топ за месяцы до атаки, eclipse через искажённый bootstrap делает «самый длинный в видимости» равным «самый длинный под управлением атакующего», постоянное прикрепление к одному хосту даёт ему полный социальный граф клиента. Раздел 11.5 закрывает эти угрозы процедурно.
11.5.1 Три стратегии выбора
Клиент выбирает стратегию при настройке, переключается в любой момент через настройки. Спецификация не предписывает стратегию по умолчанию — приложение рекомендует «Авто» для нетехнических пользователей, «Закреплённый» для технически грамотных операторов с собственными узлами или доверенными хостами.
Стратегия A — Авто. Клиент автоматически выбирает узлы-хосты по политике с несколькими критериями (см. 11.5.2). Взаимодействие без необходимости разбираться в выборе узлов. Компромисс: пользователь делегирует решение алгоритму клиента.
Стратегия B — Закреплённый. Пользователь явно указывает допустимые узлы — собственный узел, узлы доверенных контактов, узлы из community-реестра публичной утилиты (см. 11.5.5). Полный контроль, никакого автоматического выбора. Компромисс: требует от пользователя поддержания актуального белого списка при изменениях в сети.
Стратегия C — Гибрид. Авто с ограничениями — белый список (всегда предпочитать эти узлы пока они проходят критерии), чёрный список (никогда не использовать), юрисдикционные фильтры. Компромисс: средняя сложность настройки, средний контроль.
Стратегия формализована в локальной конфигурации:
HostSelectionConfig {
strategy enum (Auto | Pinned | Hybrid)
pinned_set []NodeID (для Pinned, Hybrid)
blacklist []NodeID (для Auto, Hybrid)
jurisdiction_filter []CountryCode (опционально, исключаемые юрисдикции)
parallel_connections u8 (1..16, по умолчанию 5)
rotation_period_tau2 u32 (окон τ₂ между ротациями, по умолчанию 1)
require_advisory bool (по умолчанию false; если true — узел должен быть в community-реестре)
}
11.5.2 Политика с несколькими критериями (для стратегий «Авто» и «Гибрид»)
Узел попадает в допустимое множество только если выполнены ВСЕ критерии одновременно:
| Критерий | Минимум по умолчанию | Защищает от |
|---|---|---|
chain_length ≥ min_chain_length |
2 × τ₂ (≈ 40 320 окон, ≈ 28 дней непрерывной работы) | неработающих узлов, недавно созданных sybil-узлов |
node_age ≥ min_node_age |
6 × τ₂ (≈ 84 дня от первого сцементированного BundledConfirmation) |
заранее построенных sybil-узлов специально подготовленных к атаке за короткий период |
latency_p95 ≤ max_acceptable_ms |
2000 мс | мёртвых или недоступных узлов |
not_in_blacklist |
— | известных плохих акторов из локального и community-чёрного списка |
not_in_jurisdiction_filter |
— | пользовательских предпочтений по юрисдикции |
success_rate_last_τ₂ ≥ threshold |
0.95 | узлов отказывающих в gossip операций конкретного клиента |
Все критерии настраиваемы пользователем; значения по умолчанию безопасны для типичного неагрессивного окружения. Допустимое множество пересчитывается клиентом локально из публично наблюдаемого состояния NodeChain — не требует доверия к третьей стороне. Пересчёт инкрементальный: новое сцементированное BundledConfirmation или истёкшая проба задержки → пересчёт затрагивает только относящиеся узлы.
Из допустимого множества клиент выбирает активное множество соединений через равномерный случайный выбор размером parallel_connections. Случайный выбор — структурная защита от концентрации: даже если один узел объективно «лучше всех» по критериям, вероятность что все клиенты выберут именно его — низкая.
11.5.3 Параллельные соединения и отказоустойчивость
Клиент держит N параллельных соединений к узлам-хостам одновременно (по умолчанию N = 5, диапазон 1..16, выбирает пользователь по компромиссу пропускная способность и избыточность).
Операции gossip-ятся через все N узлов параллельно. Цементирование операции не зависит от единичного узла: достаточно чтобы хотя бы один из N включил её в BundledConfirmation. Цензура единичным узлом не работает структурно — операция попадёт в сеть через другое соединение. Это превращает «один хост знает всё и может цензурировать» в «N хостов видят часть каждый, цензура требует координации большинства».
Отказоустойчивость автоматическая. При падении, таймауте соединения, явном отказе или падении success_rate ниже порога — клиент удаляет узел из активного множества, выбирает следующий из допустимого (тот же равномерный случайный выбор из оставшихся), устанавливает соединение. Никакого действия пользователя не требуется. Push на телефон отправляется только при массовом переключении (больше 50% активного множества за короткое время) — индикация системной проблемы, не отдельных ротаций.
Мягкий чёрный список с отсрочкой. Узел который систематически отказывает в gossip конкретных операций конкретного клиента (не общий офлайн / перегрузка) — попадает в локальный мягкий чёрный список с экспоненциальной отсрочкой: первое попадание — исключение на τ₁, второе — на 2 × τ₁ и так далее до постоянного локального блокирования после 8 инцидентов в одном τ₂. Мягкий чёрный список локальный (на клиента), не публикуется — это защита клиента, не санкция узлу.
11.5.4 Ротация
Активное множество соединений ротируется по расписанию (по умолчанию раз в τ₂ окон ≈ 14 дней). При ротации: один узел из активного множества заменяется на новый из допустимого, выбранный равномерно случайно. Постепенная ротация (один узел за раз, не всё множество сразу) сохраняет непрерывность gossip и не создаёт всплеск на сетевом обнаружении.
Защита от утечки метаданных. Постоянное прикрепление к одному узлу даёт ему полный социальный граф клиента: социальные связи через адреса получателей Transfer, каналы через подписки, время активности через временные метки операций, IP через соединение. Ротация размывает граф между несколькими операторами в скользящем окне. После N циклов ротации (например 6 × τ₂ ≈ 84 дня) ни один из ранее использованных узлов не имеет полной картины — каждый видел только часть активности за свой период активного членства.
Ротация выключается пользователем явно (rotation_period_tau2 = 0) для случаев где предсказуемость важнее распределения приватности: стабильная корпоративная среда, известный надёжный собственный узел, специфические требования соответствия.
11.5.5 Community-реестр публичной утилиты
Community-поддерживаемый консультативный реестр узлов, которые сами идентифицируют себя как публичная утилита — принимают хостинг любых аккаунтов без платы, без фильтрации контента, без юрисдикционных ограничений. Слой реестра не часть протокола (канонический реестр нарушил бы [I-3] — выбор узла стал бы консенсусно-значимым); это слой уровня приложения над протоколом.
Самоидентификация оператора. Узел публикует через свой operator_account декларацию через стандартный Anchor с фиксированным app_id = "montana.public_utility":
PublicUtilityDeclaration {
node_id NodeID
operator_address AccountID
policy_hash hash32 (хэш документа политики)
policy_url строка (где скачать политику открытым текстом)
contact строка (электронная почта или matrix-handle для споров)
declared_at_window u32
signature 3309 B (ML-DSA-65, подпись ключом operator_account)
}
Декларация публичная и верифицируемая любым клиентом через стандартную проверку AccountChain. Оператор несёт репутационную ответственность за соответствие декларированной политике: систематические нарушения → исключение из community-реестра.
Community-реестр. Список узлов публичной утилиты с историей репутации поддерживается несколькими независимыми maintainer-ами (рекомендация: M = 3–5 организаций не аффилированных друг с другом). Каждый maintainer подписывает свой список своим keypair. Клиент принимает узел в допустимое множество по критерию реестра если K из M maintainer-ов включили его в свой список (по умолчанию K = 2, настраиваемо).
Реестр клиент использует как подсказку для первичного допустимого множества, не как обязательный фильтр. Узел не в реестре, но проходящий политику 11.5.2 — допустим если пользователь не выставил require_advisory = true. Это сохраняет permissionless природу сети: новый легитимный узел без одобрения реестром доступен для использования.
11.5.6 Защита при первичном подключении от eclipse
Расширение 11.2 (Bootstrap-узлы) для защиты от случая когда атакующий контролирует источники первичного подключения конкретного клиента. Если все источники первичного подключения контролируются одним актором, политика 11.5.2 применяется к узлам которые видит клиент — но клиент видит только узлы атакующего, и среди них «самая длинная цепочка» = «самая длинная контролируемая атакующим». Защита — структурное первичное подключение из нескольких источников с перекрёстной верификацией.
При первом первичном подключении клиент использует несколько независимых источников одновременно:
- Хардкодированный список зерен в дистрибутиве — процесс сборки с несколькими maintainer-ами (не единый корпоративный контроль над релизным артефактом). Минимум 12 узлов из разных юрисдикций
- Зёрна DNS на разных провайдерах инфраструктуры — рекомендуется 3 или больше независимых DNS-зон (например
seed.montana.io,seed.montana.org,seed.montana-network.io) на разных регистраторах и хостингах - Опциональное первичное подключение через Tor для перекрёстной верификации из регионов с подозрением на сетевую цензуру
- Опциональный вне-сетевой верифицированный узел от доверенного контакта — QR-код или ручной ввод
NodeIDи мультиадреса
Перекрёстные проверки. Клиент сравнивает представления топологии полученные от разных источников. Если результаты значительно расходятся (больше 50% узлов из одного источника не известны второму, или непересекающиеся распределения chain_length) — предупреждение пользователю «возможна атака на обнаружение, проверьте канал первичного подключения» с детализацией расхождения. При совпадающих представлениях — высокая уверенность, переход к нормальной работе.
Периодическое повторное первичное подключение. Раз в N × τ₂ (по умолчанию N = 4, ≈ 56 дней) клиент перепроверяет источники первичного подключения для детекции долгой eclipse-атаки. Если новое первичное подключение даёт топологию значительно отличную от текущего допустимого множества — предупреждение и рекомендация пересмотреть активные соединения.
11.5.7 Индикация в интерфейсе
В «Настройки → Сеть → Хостинг аккаунта» клиент показывает:
- Текущую стратегию (Авто / Закреплённый / Гибрид) с краткой пометкой компромисса
- Активное множество соединений: список N узлов с метриками на хост —
latency p95,success rateза последний τ₂, временная метка последнего успешного gossip,node_age,chain_length, заявленная юрисдикция (если есть вPublicUtilityDeclaration), количество одобрений реестра - Временная метка последней ротации и обратный отсчёт до следующей плановой
- Здоровье источников первичного подключения: количество источников в согласии, временная метка последней перекрёстной проверки, индикаторы расхождения
- Размер допустимого множества (сколько узлов проходят политику 11.5.2 сейчас) — индикатор здоровья сети для данного клиента
Управляющие действия в интерфейсе: принудительная ротация сейчас, переключение стратегии, управление закреплёнными / чёрными списками, аварийный ручной ввод хоста (в случае массового переключения при котором допустимое множество временно пусто), запуск повторного первичного подключения.
При проблемах (массовое переключение, success_rate ниже порога по большинству хостов, расхождение первичного подключения) — push на телефон с описанием состояния и рекомендованными действиями. Пользователь не должен узнавать о проблеме хостинга случайно.
11.6 Интеграция Mesh Transport
Раздел описывает интеграцию протокольного Mesh Transport (см. раздел Mesh Transport в спеке протокола) в клиентское приложение Montana на уровне нативных платформенных API. Формат MeshFrame, типы кадров, параметры буфера и правила хранения-и-пересылки определены в спеке протокола — здесь не дублируются.
11.6.1 Режимы активации
Mesh-транспорт имеет три режима работы, пользователь выбирает в «Настройки → Сеть → Режим mesh»:
Выключен (по умолчанию). Mesh-транспорт не активируется. Приложение работает только через интернет. Рекомендуется для обычного использования — экономит батарею и не расходует радио.
По требованию. Mesh активируется автоматически когда приложение обнаруживает отсутствие интернет-соединения. При восстановлении интернета mesh деактивируется, кадры из буфера синхронизируются в сеть через интернет-шлюз. Индикатор в интерфейсе показывает текущий режим (интернет / mesh).
Всегда включён. Mesh активен постоянно параллельно с интернетом. Рекомендуется пользователям в контекстах высокого риска (активист, журналист в цензурной юрисдикции) — при внезапном отключении связь не прерывается. Расходует больше батареи (базовый расход ≈ 15–25% в сутки в зависимости от устройства).
Пользователь явно соглашается на активацию mesh при первом включении — приложение показывает объяснение: «Режим mesh использует Bluetooth и Wi-Fi Direct для связи когда интернет недоступен. Расход батареи выше. Ваше местоположение не раскрывается приложению, но устройства в радиусе Bluetooth могут видеть факт наличия Montana на вашем телефоне.»
11.6.2 Интеграция iOS
Фреймворки:
CoreBluetoothдля рекламы и сканирования BLEMultipeerConnectivityдля обнаружения сервисов аналогичного Wi-Fi Direct (высокая пропускная способность для больших сообщений)
Ограничения фонового режима. iOS ограничивает фоновые операции Bluetooth:
- Фоновый режим
bluetooth-centralразрешает сканирование в фоне, но с уменьшенной частотой - Фоновый режим
bluetooth-peripheralразрешает рекламу в фоне с пониженным приоритетом UUID сервиса - Полная функциональность mesh — только на активном экране; в фоне — пассивное прослушивание и приоритетная очередь для известных контактов
BGTaskScheduler. Периодические фоновые задачи запланированы через BGProcessingTaskRequest для периодической синхронизации буфера. iOS самостоятельно решает когда запустить задачу; приложение не гарантирует тайминг.
UUID сервиса: зарезервированный 16-байтовый UUID для сервиса mesh Montana (зарегистрирован в эталонной реализации), публикуется в данных рекламы BLE.
11.6.3 Интеграция Android
API:
BluetoothLeAdvertiserиBluetoothLeScannerдля кадров BLE meshWifiP2pManagerдля соединений Wi-Fi Direct (высокая пропускная способность)ForegroundServiceс уведомлением для долгоживущих операций mesh (Android требует видимого уведомления для фонового непрерывного BLE)
Меры приватности. На Android включена рандомизация MAC BLE — платформа ротирует аппаратный MAC каждые 15 минут по умолчанию. Дополнительно Montana ротирует mesh_session_id при переходе между сессиями mesh.
Белый список оптимизации батареи. При первом включении режима mesh приложение просит пользователя исключить Montana из оптимизатора батареи Android — без этого ОС может агрессивно приостанавливать фоновые операции.
11.6.4 Жизненный цикл сессии
- Обнаружение: приложение транслирует периодические кадры обнаружения (
frame_type = 0) с базовым темпом. Другие устройства Montana в радиусе их получают. - Совпадение контакта: если кадр адресован известному контакту (
recipient_hintсовпадает) — приложение инициирует mesh-рукопожатие IBT (см. подраздел Identity-Bound Tunnel → Mesh transport extension выше в этой спеке). - Установление сессии: после успешного рукопожатия сессия установлена,
mesh_session_idдобавлен в локальный список активных mesh-сессий. - Обмен данными: сообщения чата или blob-ы платежей передаются через кадры данных (
frame_type = 1) с аутентификацией через MAC сессии. - Пересылка: кадры не адресованные себе — хранятся в буфере mesh согласно правилам хранения-и-пересылки, оппортунистически пересылаются другим пирам.
- Закрытие сессии: явное «закрыть сессию» пользователем, либо таймаут неактивности 4 часа, либо истечение допустимой устарелости
cached_window_index.
11.6.5 Роль шлюза
Устройство с одновременным доступом к интернету и mesh действует как шлюз между изолированной областью mesh и глобальной сетью Montana:
- Кадры полученные из буфера mesh адресованные
account_idкоторые находятся за пределами mesh — пересылаются через интернет-gossip P2P к хостящему узлу получателя - Кадры полученные через интернет адресованные
account_idподключённым через mesh — помещаются в локальный буфер mesh для пересылки ближайшими пирами
Пользователь-шлюз может явно включить или отключить режим шлюза в настройках. По умолчанию включён для режима «всегда включён», выключен для «по требованию».
11.6.6 Локальное хранилище
Специфичное для mesh локальное состояние хранится в зашифрованной базе SQLite рядом с остальным состоянием приложения:
active_mesh_sessions:
mesh_session_id 32 B (первичный ключ)
peer_pubkey 1952 B (ML-DSA-65)
peer_contact_account_id 32 B (если peer в адресной книге)
session_established_at временная метка
last_activity_at временная метка
session_mac_key 32 B (выведен через HKDF из общего секрета сессии)
cached_peer_window_index u32
mesh_buffer:
frame_hash 32 B (первичный ключ)
frame_bytes blob (сериализованный MeshFrame)
received_at временная метка
ttl_remaining u8
sender_ref 32 B
forwarded_to blob (множество peer-id как сериализованный массив)
mesh_used_nonces:
sender_pubkey 1952 B
nonce 32 B
expires_at временная метка (received_at + 7 × τ₁)
PRIMARY KEY (sender_pubkey, nonce)
Мастер-ключ шифрования состояния приложения применим к этим таблицам без отличий.
Связанные спецификации
- Montana Protocol (родительский слой) — state machine, crypto, consensus.
- Montana App (дочерний слой) — UI клиенты на основе этого сетевого API.
История версий читается через git log и Код/VERSION.md.
Конец спецификации Montana Network.