Структура рабочего пространства

Репозиторий разделён по границам доказательства и доверия, а не по исполняемым файлам.

Арифметика и основа доказательств

Крейт	Назначение
`noid_core`	Бинарное башенное поле, векторизованные вычислительные ядра и выбор реализации для CPU
`noid_poseidon2b`	Перестановка Poseidon2b, домены, хеши и пакетное исполнение
`noid_fri`	Примитивы FRI
`noid_fri_binius`	Интеграция FRI-Binius/BaseFold над бинарным полем
`noid_ivc_core`	Рекурсивные публичные входы и выходы, основа проверяющей стороны
`noid_ivc_prover`	Реализация рекурсивной доказывающей стороны
`noid_gkr`	Отношения FROST-GKR и авторизация кошелька
`noid_recursive`	`HistoryStep`, отношение точного `State` и рекурсивное принятие
`bench_prover`	Генерация матриц, контрольные значения и измерение производительности доказательств

Объекты протокола

Крейт	Назначение
`noid_tx`	Фиксированный `Tx8x2`, логический `PagedSpend`, идентификаторы и связывание авторизации
`noid_block`	Композиция доказательств на уровне блока
`noid_chain`	Заголовки, консенсус, `State`, комиссии, чеки, MDBX и снимки

noid_tx содержит правила уровня представления, которые проверяются без цепи. noid_chain добавляет текущую эпоху, Live State, эмиссию, распределение и контекст ответвления цепи.

Исполнение

Крейт	Назначение
`noid_mempool`	Допуск логических транзакций, бюджет CPU, конфликты и метаданные выбора
`noid_miner`	Общий CPU-план, построение шаблона, доказательство и PoW
`noid_p2p`	Обнаружение libp2p, gossip, синхронизация и лимиты ресурсов
`noid_rpc`	Типизированный JSON-RPC API и операции кошелька
`noid_node`	Демон, CLI, состояние кошелька и оркестрация подсистем
`noid_gui`	Нативный многоязычный кошелёк и управление встроенной нодой
`noid_extminer`	Внешний вычислитель nonce Poseidon2b

Направление зависимостей

Предполагаемое направление:

field / hashes / proof primitives
            ↓
transaction and block relations
            ↓
chain consensus and storage
            ↓
mempool / miner / P2P / RPC
            ↓
нода и GUI-приложения

Нижние крейты не вызывают GUI, RPC или сетевую политику. Консенсусные типы не зависят от меток кошелька и представления приложения.

Консенсусно чувствительные изменения

Изменение относится к консенсусу, если затрагивает:

каноническое кодирование байтов;
порядок полей Poseidon2b или доменный тег;
корректность транзакции или блока;
вывод корня State;
эмиссию, сжигание комиссии или распределение;
сложность, временную метку, финальность или правила расширения;
отношение HistoryStep или аутентифицированные матрицы.

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

Изменения только приложения

Перевод, компоновка интерфейса, метки кошелька, представление журналов и обычное форматирование ответов RPC находятся вне консенсуса, пока не меняют сериализованные объекты, отправляемые ноде.

Выбор монет кошельком также является политикой. Итоговый PagedSpend обязан удовлетворять тем же правилам консенсуса, что и транзакция другой реализации.