Архитектура протокола

NOXY — постквантовый блокчейн первого уровня (Layer 1), построенный вокруг канонического транзакционного envelope, Merkle-фиксируемого леджера и DAG-консенсуса с чекпоинт-финальностью. Эта страница описывает то, что реализовано в Rust-кодовой базе.

Хэширование и разделение доменов

Все критичные для консенсуса хэши вычисляются алгоритмом BLAKE3 с префиксом домена:

BLAKE3("NOXY-L0/v0.1/<domain>\0" || data)

Примеры доменов, используемых в кодовой базе:

| Имя домена | Назначение | |:---|:---| | tx-signing | Хэширование транзакции перед подписью. | | tx-root | Корень Merkle-дерева транзакций. | | state-root | Корень Merkle-дерева состояния. | | event-root | Корень Merkle-дерева событий. |

Транзакционный envelope

Каждое действие в сети обертывается в TransactionEnvelope для сетевой передачи и валидации:

TransactionEnvelope {
  version:    u16                     // Версия формата
  chain_id:   ChainId                 // UTF-8 идентификатор сети
  account_id: AccountId               // 32-байтный адрес отправителя
  nonce:      u64                     // Порядковый номер транзакции аккаунта
  fee: Fee {
    fee_asset_id:            AssetId  // Идентификатор актива комиссии
    max_fee:                 u64      // Максимальный предел списания
    witness_byte_fee_limit:  u64      // Лимит стоимости байта подписи
  }
  payload:    TransactionPayload
  auth: AuthEnvelope {
    key_id:                    KeyId            // Идентификатор подписывающего ключа
    algorithm_id:              u16              // Алгоритм подписи (ML-DSA-44)
    signature:                 Uint8Array       // Подпись ML-DSA-44 (2420 байт)
    optional_hybrid_signature: Option<Uint8Array> // Опциональная вторая подпись Ed25519
  }
}

Типы транзакций (Payloads)

| Имя типа | Назначение | |:---|:---| | CreateAccount | Создание нового аккаунта с ML-DSA-44 ключом. | | RegisterKey | Добавление дополнительного ключа в реестр. | | Transfer | Перевод токенов между аккаунтами. | | RegisterValidator | Регистрация нового валидатора. | | Batch | Атомарный пакет из нескольких действий. | | ActivateValidator | Активация валидатора на следующую эпоху (Admin). | | DeactivateValidator | Деактивация валидатора (Admin). | | RegisterServiceDefinition| Регистрация межсетевого сервиса. | | RegisterServiceChain | Регистрация подчиненной цепочки. | | SubmitCheckpoint | Запись чекпоинта service chain. | | SubmitMessageEnvelope | Передача межсетевого сообщения. |

Консенсус

Консенсус — единый конвейер из трёх стадий; режимов консенсуса в конфигурации больше нет.

1. Доступность (availability). DAG-слой доступности собирает батчи транзакций и сертифицирует их на множестве валидаторов.
2. Упорядочивание (ordering). Слой упорядочивания непрерывно выстраивает сертифицированные батчи в единый лог транзакций.
3. Финальность. Чекпоинт-сертификаты делают упорядоченный префикс необратимо финальным.

Как только транзакция покрыта чекпоинт-сертификатом, она финальна: в NOXY нет форков, вероятностного подтверждения и реоргов. Нет и view-based pacemaker — упорядочивание работает непрерывно, а не по лидерским раундам.

Эквивокация обрабатывается внутри слоя доступности анти-эквивокационным коллектором. Это механизм живости (liveness), а не наказания; слэшинга в протоколе нет.

Батчи и чекпоинты

Батчи и чекпоинты фиксируют Merkle-корни по транзакциям, состоянию и событиям. Чекпоинт закрепляет позицию в упорядоченном логе транзакций вместе с состоянием, полученным после исполнения всего префикса до этой позиции:

Checkpoint {
  height:               u64      // Высота чекпоинта
  ordered_sequence_end: u64      // Конец покрываемого упорядоченного префикса
  state_root:           Hash32   // Фиксация состояния после исполнения префикса
  ordered_log_root:     Hash32   // Merkle-корень упорядоченного лога транзакций
}

Чекпоинт-сертификат над этими полями, подписанный множеством валидаторов, делает покрытый префикс необратимо финальным.

Состояние

Состояние фиксируется в разреженном Merkle-дереве (SMT) над 256-битными путями BLAKE3. Коммиты дерева батчируются по окнам чекпоинтов: state_root каждого чекпоинта покрывает все изменения состояния с момента предыдущего чекпоинта.

Любой аккаунт, баланс или транзакция доказуемы компактным пруфом относительно зафиксированного чекпоинта. Пруфы транзакций доступны через публичный RPC:

GET /v0/tx/{hash}/proof?level=inclusion|finality|checkpoint

Начиная с уровня finality ответ дополняется чекпоинтом и его сертификатом (checkpoint_hex, checkpoint_cert_hex), так что пруф выстраивается вплоть до подписанного валидаторами чекпоинта.

Персистентность атомарна: записи состояния, узлы дерева и индексы попадают в RocksDB атомарно в рамках одного коммит-батча.

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

1. Криптография аккаунтов: Подписи ML-DSA-44 (FIPS 204). Публичный ключ — 1312 байт, подпись — 2420 байт.
2. Гибридные сертификаты консенсуса: Сертификаты консенсуса подписываются гибридной схемой ML-DSA-44 + Ed25519. Валидация требует обеих подписей, fallback-схема на одну подпись не предусмотрена.

Жизненный цикл валидатора

Candidate → Active → Inactive | Exiting → Exited

| Статус | Описание | |:---|:---| | Candidate | Зарегистрирован, но активация ещё не запланирована. | | Active | В текущем активном наборе: сертифицирует батчи и подписывает чекпоинты. | | Inactive | Деактивирован, не входит в активный набор. | | Exiting | Запланирован к выводу на active_until_epoch. | | Exited | Полностью удалён из набора валидаторов. |

Запись валидатора связывает:

• operator_account_id — аккаунт, владеющий действиями жизненного цикла;
• pq_consensus_key_id — ML-DSA-44 ключ для подписей сертификатов консенсуса;
• classical_consensus_key_id — парный Ed25519 ключ гибридной схемы;
• voting_power — вес валидатора при сертификации;
• active_from_epoch / active_until_epoch — членство, ограниченное эпохами.

Активный набор всегда выводится из зафиксированного состояния, а не из локальной конфигурации: нода после рестарта восстанавливает членство из БД, не откатываясь к genesis или устаревшему снапшоту конфига.