efir369999/montana
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
f26e622070
montana/Монтана-Протокол/Архив/TimeChain v10.0.0.md

28 KiB
Raw Blame History

TimeChain — Спецификация протокола Montana

Версия: 10.0.0 (2026-03-30)

Определение

Децентрализованная сеть. Время — единственная реальная валюта. 1 секунда присутствия узла в сети = 1 Ɉ.

Консенсус: Proof of Time (PoT) — последовательное SHA-256 хэширование (VDF) как доказательство прошедшего времени. Один криптографический примитив — SHA-256. Временные окна возникают из вычислений.

Генезис: 09.01.2026 00:00:00 MSK.

Криптография

Единственный примитив — SHA-256. Подписи, адреса, консенсус, Merkle-деревья построены на SHA-256.

Квантовая устойчивость обеспечивается природой хэш-функции: алгоритм Гровера сокращает безопасность с 256 до 128 бит.

Подписи — WOTS+ (Winternitz One-Time Signature)

Хэш-подпись на SHA-256. Каждый ключ используется однократно — одна подпись на один UTXO. Приватный ключ представляет собой начальные значения хэш-цепочек. Подпись содержит промежуточные точки цепочек, позиция которых кодирует подписываемое сообщение. Подпись математически привязана к конкретной транзакции.

Параметр w=256:

Компонент Размер
Приватный ключ (seed) 32B
Публичный ключ (сжатый) 32B
Подпись 1 120B

Деривация ключей: secret_n = SHA-256("montana-tx" || seed || n). Один seed (32B) порождает цепочку одноразовых ключей через инкрементальный counter.

Адреса

Формат: mt + Base58(SHA-256(pubkey) + checksum). Деривация ключей и адресов описана в разделе «Ключи».

Транзакции — UTXO модель

Модель неизрасходованных выходов. Каждая транзакция потребляет существующие UTXO и создаёт новые.

Формат транзакции

Компонент Размер
WOTS+ подпись 1 120B
UTXO reference (tx_hash + index) 36B
Выходы (2 × (address 49B + amount 8B)) 114B
Slot index 4B
Итого ~1.3 KB

Вход: WOTS+ подпись (привязана к данным транзакции) + ссылка на UTXO. Выход: адрес получателя + сумма.

Верификация баланса

sum(входы) = sum(выходы) + fee. Каждый узел проверяет баланс арифметическим сложением.

Dust limit: каждый выход ≥ 1 Ɉ (MINIMUM_UTXO).

Комиссия

Комиссия = разница между суммой входов и суммой выходов. Минимум 1 mɈ (миллисекунда). Размер адаптивный — рассчитывается по формуле на основе заполненности окон τ₁. Пользователь знает комиссию до отправки.

Победитель окна τ₂ получает сумму всех комиссий транзакций в окне.

UTXO

Формат: {address, amount, tx_hash, output_index}.

UTXO существует до момента траты. Трата фиксируется использованием WOTS+ подписи. Повторная трата исключена конструкцией данных.

Coinbase

Победитель τ₂ создаёт coinbase-транзакцию. Входов нет. Выходы содержат эмиссию за τ₂ + сумму комиссий всех транзакций окна.

Supply audit при финализации τ₂: суммарная эмиссия coinbase от генезиса сверяется с расчётной по формуле халвинга.

Таймчейн

Три логических двигателя с односторонним потоком зависимостей: Beacon → Service → Execution.

Beacon — глобальные часы протокола

Непрерывная последовательная SHA-256 цепочка. Общий источник случайности и ритм сети:

B_r = SHA-256^D(B_{r-1})

D — количество последовательных хэшей за один слот τ₁. Beacon продвигается по расписанию финализированных слотов. Для фиксированного индекса r значение B_r совпадает у всех честных узлов. Каждый узел вычисляет Beacon независимо — результат детерминирован.

Beacon не зависит от состояния, транзакций и поведения отдельных узлов.

Service — персональный VDF узла

Доказательство непрерывного присутствия конкретного node_id. Якорится в Beacon каждый слот:

S_{i,s,0}   = SHA-256(S_{i,s-1,m} || B_s || node_id_i)
S_{i,s,j+1} = SHA-256(S_{i,s,j})    для j = 0..m-1

Три компонента seed: предыдущий endpoint (непрерывность службы), значение Beacon (протокольное время), node_id (идентичность). m последовательных хэшей за слот — доказательство работы.

Service зависит от Beacon. Beacon не зависит от Service.

Execution — содержимое блока

Приём, верификация транзакций (WOTS+ подписи, баланс) и формирование канонического набора.

Транзакция получает Inclusion Certificate (IC) когда её наличие подтверждено подписанными чекпоинтами суммарного веса >2/3 active set. Канонический набор τ₂ состоит из всех транзакций с валидным IC, полученным до cutoff последнего слота окна. Канонический порядок: (earliest_certified_slot, txid). Конфликты UTXO разрешаются правилом first valid in canonical order wins.

Победитель лотереи собирает блок механически по этим правилам, добавляя coinbase. Отклонение от правил — невалидный блок, переход ко второму месту. Любой узел независимо вычисляет тот же набор и тот же порядок.

Execution зависит от Beacon и Service. Обратных зависимостей нет.

С ростом TPS сети дополнительные ядра подключаются для верификации транзакций. Минимум для валидатора: 3 логических ядра (Beacon + Service + Execution).

Чекпоинт

Каждый валидатор в каждом слоте τ₁ публикует подписанный чекпоинт:

CP_{i,s} = Sig_i(epoch, slot, B_s, S_{i,s,m}, tx_root_{i,s})

Чекпоинт связывает протокольное время (B_s), доказательство службы (S_{i,s,m}) и локальную картину транзакций (tx_root) в одну подписанную аттестацию.

Входной барьер — Adaptive Cooldown

Допуск к консенсусу определяется Adaptive Cooldown — динамическим входным периодом, чувствительным к темпу роста сети.

Формула

Скользящее окно из 3 последних τ₃ (42 дня). Темп роста — процент новых регистраций от количества активных узлов. Медиана трёх последних значений определяет норму:

growth_rate = new_registrations_in_τ₃ / active_nodes_at_start × 100%
median = median(growth_rate за 3 предыдущих τ₃)
excess = ((current_growth - median) / median) × 100%

excess ≤ 0%:          cooldown = 7 дней
0% < excess ≤ 100%:   cooldown = 7 + excess × 35 / 100
excess > 100%:        cooldown = 42 дня

Минимум 7 дней. Максимум 42 дня (3 × τ₃).

Bootstrap: effective_median = max(median, 1%), effective_active = max(active_nodes, 10).

Асимметрия

Повышение cooldown — немедленное, без ограничений. Снижение — не быстрее 20% за τ₃. Атака поднимает барьер мгновенно. Возврат к норме занимает месяцы.

Реакция внутри τ₃

Cooldown пересчитывается в реальном времени по проекции темпа на конец окна:

projected_growth = current_registrations / elapsed_fraction
elapsed_fraction = elapsed_slots / total_slots_in_τ₃

Счётчик регистраций детерминирован: считаются только сертифицированные регистрации (с IC) в каноническом порядке (slot, txid).

Фиксация

Cooldown закрепляется за узлом в момент регистрации. Пересчёт не меняет cooldown уже зарегистрированным узлам.

Во время cooldown

Узел запускает Beacon + Service VDF сразу при регистрации. Валидирует транзакции, ретранслирует данные, публикует чекпоинты. Узел усиливает сетевой слой и несёт стоимость допуска к консенсусу. Стоимость каждого Sybil-узла: 1 service-core непрерывно на весь период cooldown.

После cooldown

Вес начинается с 0 и растёт линейно с каждым подписанным τ₂. Работа во время cooldown полезна сети, но не конвертируется в консенсусный вес.

Потоковая модель транзакций

Транзакции текут непрерывно. Узел получает транзакцию → проверяет подпись и баланс → передаёт в P2P gossip. Время подтверждения определяется скоростью интернета отправителя и P2P-распространением (~2-5 секунд).

Транзакция включается в канонический набор τ₂ при получении Inclusion Certificate (>2/3 активного веса подтвердили через чекпоинты). Транзакции не ожидают появления τ₁ или τ₂ — окна являются чекпоинтами, а не условиями приёма.

Временные слои (τ)

τ₁ (≈60с) → τ₂ (10 × τ₁) → τ₃ (2016 × τ₂) → τ₄ (~104 × τ₃)

τ₁ — Слот (≈60 секунд)

  • Beacon продвигается на D хэшей
  • Service VDF продвигается на m хэшей с якорем в текущем B_s
  • Валидаторы публикуют подписанные чекпоинты CP_{i,s}
  • Узлы обмениваются чекпоинтами и транзакциями по P2P
  • Транзакции набирают Inclusion Certificates

τ₂ — Финализация и эмиссия (10 × τ₁ ≈ 10 минут)

  • Active set (состав и веса участников) фиксируется в начале τ₂
  • Канонический набор: все транзакции с валидным IC до cutoff последнего слота
  • Лотерея: ticket_i = S_{i,final,m} / weight_i, победитель = min(ticket_i) среди допущенных
  • Победитель публикует proposal блока (канонический набор TX + coinbase)
  • Финальность: Quorum Certificate (QC) на заголовок блока от >2/3 активного веса
  • Seed следующей эпохи: seed_i = SHA-256(B_r || active_set_root_r || node_id_i)
  • Coinbase: вся эмиссия + все комиссии → победителю
  • Supply audit: суммарная эмиссия coinbase от генезиса сверяется с расчётной
  • Разрешение форков: приоритет ветки с наибольшим суммарным Beacon-доказательством

Beacon safety: компрометация значения Beacon требует нарушения свойства последовательности SHA-256 VDF или подделки finality certificate порогом >2/3 активного веса.

Beacon liveness: задержка продвижения Beacon требует блокировки finality порогом >1/3 активного веса.

τ₃ — Адаптация (2016 × τ₂ ≈ 14 дней)

  • Калибровка D и m: медиана слотовых интервалов сверяется с целевыми, цель τ₁ ≈ 60 секунд
  • UTXO Merkle Root: включается в заголовок последнего τ₂, ратифицируется QC
  • Криптографическая амнезия: тела транзакций и WOTS+ подписи старше 8 × τ₃ удаляются. Цепочка заголовков τ₂ (Beacon, QC hash, UTXO root, tx root) сохраняется навсегда
  • Вызов архивных узлов: retention audit по случайному историческому блоку, архивный узел предоставляет данные + Merkle proof
  • Пересчёт параметров окна τ₁

τ₄ — Халвинг (~104 × τ₃ ≈ 4 года)

  • Коэффициент эмиссии делится на 2

Консенсус — Proof of Time (PoT)

Три двигателя

Beacon — глобальные часы. Чистая VDF-цепочка B_r = SHA-256^D(B_{r-1}). Источник случайности для лотереи. Продвигается по расписанию финализированных слотов.

Service — персональный VDF. Якорится в Beacon каждый слот. Доказывает непрерывное присутствие node_id. Определяет вес и лотерейный билет.

Execution — содержимое блока. Канонический набор TX определяется Inclusion Certificate (>2/3 активного веса). Порядок детерминирован. Победитель собирает блок механически.

Зависимости односторонние: Beacon → Service → Execution. Отказ в Execution не заражает случайность. Отказ конкретного узла в Service не заражает общий ритм.

Стаж и вес

Определение

Вес узла — длина его непрерывной Service цепочки, измеренная в подписанных τ₂:

weight_i = min(chain_length_i, MAX_WEIGHT)
MAX_WEIGHT = количество τ₂ в одном τ₄ (~105 000)

Вес — единственная мера влияния узла в протоколе. Определяется только временем непрерывной службы.

Как растёт

Цепочка растёт на 1 за каждый τ₂ с засчитанным участием. Участие в τ₂ засчитывается при публикации не менее k валидных чекпоинтов из n слотов окна (k=8, n=10). Чекпоинт валиден при выполнении условий: подписан ключом node_id, содержит корректные epoch и slot, якорится в соответствующий Beacon slot, получен сетью до конца следующего слота.

Обрыв

Если узел за период τ₃ отработал менее 1613 из 2016 окон τ₂ — цепочка обрывается, weight = 0. Узел начинает копить длину заново. Adaptive Cooldown повторно не проходится (node_id уже зарегистрирован).

Три зоны

  • Cooldown (7-42 дня): допуск закрыт, weight = 0, узел работает как валидатор и ретранслятор
  • После cooldown — 4 года: weight растёт линейно с каждым подписанным τ₂
  • 4+ года (≥ τ₄): weight = MAX_WEIGHT, потолок

Потолок τ₄ предотвращает бесконечный рост преимущества ранних участников. Все цепочки старше 4 лет равны между собой.

На что влияет вес

Вес определяет три вещи:

1. Лотерея. Вероятность победы в τ₂ пропорциональна весу:

ticket_i = S_{i,final,m} / weight_i
winner = min(ticket_i)
P(node_i) = weight_i / Σ weight(all_nodes)

Больше вес → меньше ticket → выше шанс. Узел с weight = 0 не участвует в лотерее.

2. Голосовая сила в консенсусе. Inclusion Certificate и Quorum Certificate считаются по весу, а не по количеству узлов:

IC валиден:  Σ weight(подтвердивших) > 2/3 × Σ weight(active_set)
QC валиден:  Σ weight(подписавших)   > 2/3 × Σ weight(active_set)

Голос узла в IC и QC пропорционален его weight. Sybil-атака через 1000 свежих узлов (weight ≈ 0 каждый) не даёт голосовой силы. Для контроля консенсуса атакующий должен накопить >1/3 суммарного веса сети — это годы непрерывной службы.

3. Допуск. weight = 0 означает: узел участвует в сети (валидация, ретрансляция), но не участвует в лотерее и не имеет голосовой силы в IC/QC.

Победитель τ₂

Победитель определяется после закрытия окна τ₂. Каждый узел раскрывает свой Service VDF endpoint. Минимальный ticket среди допущенных — победитель (формула в разделе «На что влияет вес»).

Победитель публикует proposal блока: канонический набор TX (определён IC) + coinbase. Содержимое блока детерминировано правилами IC и каноническим порядком. Свобода победителя в формировании блока: ноль.

Финальность блока возникает после QC на заголовок от >2/3 активного веса.

Верификация

Победитель публикует: {node_id, Service checkpoints[], proposal}.

Верификация Service VDF: пересчёт K сегментов параллельно. K ≈ 960. На C ядрах: ~(K/C) × t_segment секунд. 8 ядер → ~7.5 сек. 64 ядра → ~1 сек.

Верификация proposal: независимый расчёт канонического набора по IC и сравнение с proposal.

Устойчивость

  • Proposer grinding исключён: победитель не выбирает состав блока, канонический набор определяется IC (>2/3 активного веса)
  • Committee grinding исключён: Beacon не зависит от состояния и транзакций, seed лотереи строится из Beacon
  • Node_id гриндинг исключён: Adaptive Cooldown (7-42 дня), Beacon неизвестен при регистрации
  • Предвычисление исключено: seed содержит текущее значение Beacon
  • Replay исключён: Beacon уникален для каждого τ₂
  • Аппаратное преимущество ограничено: последовательное хэширование масштабируется тактовой частотой и IPC, а не количеством ядер или бюджетом
  • Sybil-барьер: Adaptive Cooldown (7-42 дня, асимметричный) + Service VDF (физическое ядро) + линейный рост веса от нуля
  • Аристократия ограничена: потолок веса τ₄, после 4 лет все равны

Адреса и переводы

Полный флоу перевода

1. Боб: кошелёк генерирует keypair_7 → address_7
2. Боб → Алисе: "отправь на mt4ZGfe..." (address_7)
3. Алиса формирует транзакцию:
   Вход:  UTXO на 80 Ɉ (address_3)
   Выход: 50 Ɉ → address_7 (Бобу)
   Выход: 30 Ɉ → address_12 (сдача, новый адрес)
4. Алиса подписывает WOTS+ (привязано к выходам)
5. Алиса рассылает транзакцию узлам сети
6. Каждый узел проверяет:
   WOTS+ подпись валидна для pubkey address_3 ✓
   80 = 50 + 30 ✓
7. Транзакция распространяется через P2P gossip
8. Транзакция получает IC (>2/3 валидаторов подтвердили в чекпоинтах)
9. При финализации τ₂: UTXO address_3 потрачен
10. Созданы UTXO: 50 Ɉ @ address_7, 30 Ɉ @ address_12

Баланс

Кошелёк деривирует все адреса из seed, сканирует UTXO set. Сумма непотраченных UTXO = баланс.

Бэкап = seed (32 байта).

Эмиссия

Единица

1 секунда Montana = 1 $MONT = 1 Ɉ = 1 000 mɈ = 1 000 000 μɈ = 1 000 000 000 nɈ

Точность: 9 знаков после запятой (наносекунда).

lim(t → ∞) 1 Ɉ → 1 секунда. Халвинг делает Ɉ дефицитнее, секунды идут с постоянной скоростью. Чем дальше от генезиса, тем ценнее каждый Ɉ, тем ближе он к реальной секунде.

Параметр Значение
Генезис 09.01.2026 00:00:00 MSK
Эмиссия за τ₂ 50 минут (3 000 Ɉ)
Халвинг ÷2 каждые τ₄
TIME_BANK 21 000 000 минут (~40 лет)
После истощения Oracle Mode (верификация)
Эпоха Годы Эмиссия за τ₂
τ₄ #0 0-4 50 мин (3 000 Ɉ)
τ₄ #1 4-8 25 мин (1 500 Ɉ)
τ₄ #2 8-12 12.5 мин (750 Ɉ)
τ₄ #3 12-16 6.25 мин (375 Ɉ)

Распределение

Победитель τ₂ получает всю эмиссию + все комиссии окна. Один выход в coinbase.

Якорь цены — Bitcoin

1 BTC = block_interval ÷ block_reward
1 BTC = 600 ÷ 3.125 = 192 Ɉ (эпоха 2024-2028)
Эпоха Награда за блок 1 BTC = Ɉ
2024-2028 3.125 BTC 192
2028-2032 1.5625 BTC 384
2032-2036 0.78125 BTC 768

Константа между халвингами. Справочная привязка, протокол функционирует автономно.

Пропускная способность

Размер транзакции: ~1.3 KB.

Канал узла TPS
10 Mbps ~960
100 Mbps ~9 600
1 Gbps ~96 000

Адаптивный размер окна

Пересчёт в τ₃:

  • Заполненность > 80% → увеличение размера окна
  • Заполненность < 20% → уменьшение размера окна
  • Шаг: ±20% за τ₃
  • Диапазон: 1 MB — 100 MB

Хранение

TPS Архивный (20 лет) Полный (112 дней) Pruned SPV
7 ~6 TB ~80 GB ~15 GB ~1 GB
100 ~88 TB ~1.1 TB ~15 GB ~1 GB
960 ~850 TB ~10.5 TB ~15 GB ~1 GB
Тип узла Содержимое Лотерея
Полный Скользящее окно 8 × τ₃ + UTXO set + заголовки weight × 1
Архивный Полная история от генезиса weight × 1 + archive reward
Pruned UTXO set + заголовки + UTXO snapshots τ₃ Наблюдатель
SPV Заголовки + собственные транзакции Наблюдатель

Узел самостоятельно выбирает тип. Участие в лотерее: полный или архивный узел. Архивные узлы получают отдельную archive reward за прохождение retention audit.

Fast Sync (новый узел)

  1. Цепочка заголовков τ₂ от генезиса — проверка Beacon-цепочки и QC (мегабайты)
  2. UTXO Merkle Root из последнего τ₃
  3. UTXO snapshot — проверка SHA-256(snapshot) == UTXO Merkle Root (гигабайты)
  4. Транзакции с подписями за последние 112 дней (скользящее окно)
  5. Узел синхронизирован и готов к участию

Ключи

seed (32B)
├── Транзакции: SHA-256("montana-tx" || seed || counter)
└── Идентификатор узла: SHA-256("montana-node" || seed)

Все деривации — SHA-256.

Зависимости

Библиотека Назначение
hashlib (stdlib) SHA-256
sqlite3 (stdlib) Хранение
socket (stdlib) P2P сеть

Base58, Merkle-деревья, WOTS+, VDF — собственная реализация. Production: C/Rust.

Архитектура

┌─────────────────────────────────┐
│  Wallet                         │
│  Кошелёк, баланс, переводы     │
└──────────────┬──────────────────┘
               │
┌──────────────┴──────────────────┐
│  TimeChain                      │
│                                 │
│  Beacon ──→ Service ──→ Execution
│  (часы)    (служба)   (состояние)
│                                 │
│  τ₁/τ₂/τ₃/τ₄, UTXO, IC, QC   │
│  WOTS+, SHA-256, Base58        │
└─────────────────────────────────┘