Оборудование и ресурсы

В Parano1d возраст цепи не превращается в постоянное требование по воспроизведению истории. Тем не менее ноде нужны CPU для проверки доказательств, память для ограниченной сетевой работы и диск для Live State. Проверяйте именно машину, видимую процессу: модель физического CPU у провайдера ещё не гарантирует, что виртуальная система получит нужные инструкции.

Минимальный набор инструкций

Рабочий бинарник поддерживает две архитектуры:

Скалярная реализация служит тестовым эталоном; штатная нода не использует её как резервный вариант. На неподдерживаемой машине процесс завершится до открытия кошелька или базы цепи.

Запустите предварительную проверку на целевой машине:

parano1d --check-hardware
parano1d-miner --check-hardware

Успешный отчёт ноды заканчивается строкой:

NODE READY

В отчёте также указана выбранная при запуске реализация. На x86-64 выбирается pclmul, avx2+vpclmul или avx512bw+vpclmul, на ARM64 — neon+pmull.

Виртуальные машины

Некоторые гипервизоры скрывают PCLMULQDQ или показывают устаревший универсальный CPU, даже если физический сервер новее. До оплаты виртуального сервера:

1. убедитесь, что гостевая система 64-битная;
2. по возможности включите прямую передачу возможностей процессора (host passthrough) или выберите современный профиль виртуального CPU;
3. загрузите именно выбранный тариф и выполните --check-hardware;
4. откажитесь от него, если процесс выводит CPU UNSUPPORTED.

На Linux x86-64 видимые гостевой системе флаги можно проверить так:

grep -m1 '^flags' /proc/cpuinfo \
  | tr ' ' '\n' \
  | grep -E '^(sse4_1|pclmulqdq|avx2|vpclmulqdq|avx512)'

Окончательной остаётся предварительная проверка штатного бинарного файла: она проверяет тот же вычислительный путь, которым воспользуется нода.

Проверенная нагрузка

Квалификация получателя использовала четыре CPU, 8 GiB RAM, без swap, PCLMUL. Полные нагрузки Small и Large прошли с пиком получателя 1,65 GiB в этом сценарии. Оставляйте запас на трафик, рост State, кошелёк и снимки. Замеры разделяют подготовку, проверку и применение и указывают условия каждой нагрузки.

Производители используют серверные ресурсы для построения доказательств и поиска nonce. Small m23 используется по умолчанию; Large m24 требует --v2-large-blocks. Подбирайте память и CPU производителя под состав блоков. Сиды и проверяющие ноды проверяют полученные доказательства. Квалификация получателя на четырёх CPU относится к ресурсам проверки. Важны поколение CPU, инструкции, память и реальная квота планировщика. Используйте SSD или NVMe и контролируйте свободное место.

Использование памяти

Основные недоверенные пулы ограничены:

• до 1 024 транзакций в мемпуле и 384 МиБ сериализованных логических транзакций;
• до 128 МиБ сохранённых пакетов блоков без известного родителя;
• за раз декодируется один аутентифицированный сегмент снимка. Обычные сегменты ограничены 8 МиБ, нативные дополнительно несут ограниченное замыкание раскрытий;
• полезная нагрузка снимков обрабатывается последовательно;
• окна недавних полных блоков и данных отката имеют фиксированный размер.

Общий RSS также включает матрицы доказательств, рабочие области доказывающей стороны, страницы базы, сеть и операционная система. Оставляйте запас и не устанавливайте лимит службы равным RSS в простое.

Встроенный майнинг использует единый бюджет потоков для построения доказательства и поиска nonce. Значение --cpu-threads должно соответствовать логическим CPU, реально выделенным службе, а не объявленному числу процессоров физического хоста.

Использование диска

Честной фиксированной цифры на весь срок жизни ноды не существует. Постоянное хранилище содержит:

• компактные заголовки за всю цепь;
• Live State и индекс владельцев;
• тела последних 42 канонических блоков;
• данные отката State за 36 блоков;
• идентификатор и хранилище пиров;
• кеш доказательств и временные данные подготавливаемых снимков;
• ключи, метаданные и чеки кошелька, если он используется.

Исторические тела транзакций не накапливаются бесконечно. Текущие активные UTXO накапливаются: объём диска зависит от заполнения State и распределения занятых сегментов. MDBX по необходимости растёт шагами по 64 MiB.

Контролируйте реальный путь:

du -sh ~/.parano1d/data
parano1d-cli state

Для синхронизации по снимку требуется временное место под полную копию State до её атомарной установки. Оставляйте место для установленного State, ещё одной подготовленной копии и обычного роста базы.

Сеть

Разрешите постоянные исходящие TCP-соединения, а на публичной ноде — входящий TCP 9600. Разумная отправная точка — безлимитный канал 100 Мбит/с. Стабильность и отсутствие жёстких лимитов соединений или трафика важнее задержки.

RPC на TCP 9601 — административный интерфейс. Оставляйте его на локальном интерфейсе, если доступ не защищён приватным или аутентифицированным транспортом.

Контроль ресурсов

Пересматривайте ресурсы при заметном изменении размера Live State или трафика:

parano1d-cli status
parano1d-cli state
parano1d-cli peers
du -sh ~/.parano1d/data

Настройте предупреждения о нехватке диска, постоянной потере пиров, продолжительном отставании и перезапусках службы. Развёртывание описано в руководстве по запуску ноды на Linux, планирование CPU майнера — в разделе встроенного майнинга.

Нативные сегменты

Native использует m24 и проверяет нативные финансовые операции в общем доказательстве. getNativeProtocol возвращает его лимиты. При сегменте из 65 536 слотов верхний предел нативного сообщения равен 21 889 045 байтам, примерно 20.88 МиБ. В него входят разреженные слоты, служебный заголовок и не более двух раскрытий по 140 байт с полями длины на слот. Декодер проверяет границы и соответствие раскрытий слотам перед установкой State.