NOXYDocs
GitHub
Docs/Начало/NOXY Wiki

NOXY Wiki

Справочник постквантового Layer 1 блокчейна NOXY: подписи ML-DSA-44, DAG-консенсус с чекпоинт-финальностью, аккаунты и публичный RPC.

Обновлено 2026-08-03Статус ReferenceИсточник content/wiki/ru/index.mdx

NOXY Wiki

NOXY — постквантовый Layer 1 блокчейн на Rust. Протокол использует ML-DSA-44 (FIPS 204) для подписей аккаунтов и гибридную схему ML-DSA-44 + Ed25519 для консенсусных сертификатов валидаторов. Состояние коммитится в разреженное Merkle-дерево над путями BLAKE3; консенсус — DAG с непрерывным упорядочиванием транзакций, финальность обеспечивают чекпоинт-сертификаты.

Wiki описывает протокол в том виде, в котором он работает на testnet Veylith: сеть veylith-testnet-10, протокол v4, целевое время блока 250 мс, четыре валидатора.

Быстрый старт

Самый быстрый способ пощупать сеть — публичный RPC:

curl https://test.noxycore.io/v0/health
curl https://test.noxycore.io/v0/node/identity
curl https://test.noxycore.io/v0/network/stats

Дальше:

  • Получите тестовые токены в faucet.
  • Собирайте и отправляйте транзакции через TypeScript SDK (@noxy/core) — он использует то же каноническое кодирование, что и нода, и сверен по общим тест-векторам.
  • Полный справочник эндпоинтов — в Developer RPC.

Сама нода публично пока не распространяется. Ядро становится source-available к mainnet, а до этого откроется программа валидаторов с подписанными бинарниками и Docker-образом; сегодня набор валидаторов — фиксированная группа операторов. Текущее состояние — в разделе Запуск ноды.

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

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

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

Разделение алгоритмов подписи по назначению:

| Где | Алгоритм | Назначение | |:---|:---|:---| | Транзакционный envelope | ML-DSA-44 | Авторизация аккаунта | | Консенсусный сертификат | ML-DSA-44 + Ed25519 (обе обязательны) | Сертификация валидаторами |

Публичный ключ ML-DSA-44 — 1312 байт, подпись — 2420 байт. Ключ Ed25519 — 32 байта, подпись — 64 байта. Сертификат с одной валидной подписью отклоняется: ни один алгоритм не является запасным для другого.

Консенсус и финальность

Батчи транзакций проходят через DAG: слой доступности собирает и сертифицирует батчи, слой упорядочивания выстраивает их в последовательность, а чекпоинт-сертификаты делают упорядоченный префикс окончательным. Форков и вероятностного расчёта нет: закоммиченный блок не реорганизуется.

Защита от эквивокации обеспечивается коллектором доступности как liveness-механизм. Слешинга стейка в протоколе сегодня нет.

Состояние

Разреженное Merkle-дерево над 256-битными путями BLAKE3 фиксирует каждое изменение состояния. Любой аккаунт, баланс или транзакцию можно доказать против закоммиченного чекпоинта компактным доказательством; доказательства транзакций отдаёт публичный RPC (GET /v0/tx/{hash}/proof).

Публичный RPC

Публичный HTTP-фасад обслуживает эти маршруты; форматы запросов и ответов — в Developer RPC.

| Эндпоинт | Назначение | |:---|:---| | GET /v0/health | Liveness фасада | | GET /v0/network/stats | Сеть, чекпоинт, валидаторы, статус EVM lane | | GET /v0/node/identity | Chain ID, genesis-хэш, нативный актив, версии | | GET /v0/economics/summary | ID нативного актива | | GET /v0/account/{id} | Запись аккаунта (нативный ID или EVM 0x-адрес) | | GET /v0/account/{id}/nonce | Sequence nonce | | GET /v0/account/{id}/balance/{asset} | Баланс актива | | GET /v0/account/{id}/activity | Активность аккаунта с пагинацией | | POST /v0/tx/submit | Отправка TransactionEnvelope (base64) | | GET /v0/tx/{hash} | Статус транзакции и display-квитанция | | GET /v0/tx/{hash}/proof | Merkle-доказательство до подписанного чекпоинта | | POST /v0/evm | Фасад eth JSON-RPC для EVM lane |

Операторская модель

Запуск ноды привязан к идентичности сети. Нода отказывается стартовать, если:

  • chain_id в конфиге не совпадает с genesis.chain_id;
  • ожидаемый genesis-хэш не совпадает с вычисленным;
  • существующая база данных проштампована другим chain_id или genesis-хэшем.

Активный набор валидаторов выводится из закоммиченного состояния, а не из локального конфига. Нода с существующей базой присоединяется заново без вайпа состояния.

Разделы документации