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

«Эксплуатация и проверки здоровья децентрализованных узлов приватности приватности» — официальная локализованная страница документации AeroNyx. AeroNyx разделяет протокольный слой и продуктовый опыт: протокол дает открытые устойчивые возможности, а App, Nodeboard, зашифрованный чат, зашифрованное хранение и эксплуатация узлов формируют пользовательский опыт.

Обзор

Эта страница на русском объясняет роль «Эксплуатация и проверки здоровья децентрализованных узлов приватности приватности» в открытом протоколе приватности AeroNyx, текущий объем реализации, инварианты приватности и замечания для разработки и эксплуатации.

Роль в архитектуре AeroNyx

Тема относится к Операторы узлов. AeroNyx следует понимать не как один централизованный сервис, а как набор возможностей протокола, которыми совместно пользуются клиенты, Rust-узлы, backend-координаторы и Nodeboard.

Текущие акценты реализации

• Все возможности, связанные с пользовательским содержимым, должны передаваться как сквозное шифрование или зашифрованные объекты.
• Rust-узлы могут сообщать здоровье, емкость, соединения, доказательства маршрута и агрегированную статистику, но не читать сообщения, учетные данные или секреты пользователя.
• Nodeboard дает операционную наблюдаемость: здоровье узла, peer discovery, восстановление после перезапуска, емкость, пакеты/трафик и состояние протокола.
• На текущем этапе backend координирует, упорядочивает, агрегирует и предоставляет публичные API документации; часть обязанностей позже может перейти в Rust-слой.

Граница приватности

Ключевой инвариант AeroNyx — blind-node invariant: relay-узлы и координаторы MemChain обрабатывают только ciphertext, временные метки, доказательства, агрегированные сигналы здоровья и ограниченные метаданные маршрутизации. Они не должны читать открытый текст, DNS, назначения или восстанавливать социальные связи.

Что важно операторам узлов

Операторы должны отслеживать пропускную способность, лимиты соединений, IP-пул, conntrack, файловые дескрипторы, packet drops, pps, bps, peer store, свежесть heartbeat и restart recovery. Интерфейс должен помогать диагностике, но не раскрывать пользовательское содержимое или коррелируемые данные.

Интеграция для разработчиков и продуктов

Клиенты, App, AI agents и сторонние сервисы должны переиспользовать шифрованные envelope, подписи, blind relay, анонимные учетные данные и healthchecks AeroNyx. Любой новый API должен отделять публичные метаданные от полей, которые остаются внутри E2E payload.

Текущее состояние

Эта страница описывает текущую публичную границу протокола и продукта AeroNyx. multi-hop routing, blind-signed vouchers, encrypted media blob, синхронизация MemChain и улучшения node discovery должны поддерживаться под тем же translation_key.

Эксплуатация закреплённых witness-узлов

Закреплённые witness — явная политика доверия оператора для MemChain-координатора. Указывайте только независимо управляемые и проверенные follower-узлы, которые должны сохранять историю обязательств этого координатора.

[memchain]
commitment_coordinator_enabled = true
commitment_witness_node_ids = ["<64-hex-ed25519-node-id-1>", "<64-hex-ed25519-node-id-2>"]
commitment_witness_startup_required = false
commitment_witness_min_verified = 2

До проверки замените все placeholders. Допускается не более трёх уникальных ненулевых 32-байтовых Ed25519 ID; параметры действуют только для координатора.

Безопасный rollout: обновите минимум два независимо проверенных follower-узла; добавьте их точные ID при выключенном strict; выполните aeronyx-server validate -c /etc/aeronyx/server.toml; перезапустите и убедитесь, что operator_pinned принимает подписанные свидетельства; только после повторной проверки включите strict.

Без strict недоступность witness вызывает явное degraded-предупреждение, но сохраняет доступность. Подписанный remote-ahead или divergence всегда блокирует запуск. Со strict отсутствие любого проверенного свидетельства также блокирует запуск.

Checkpoint — подписанный протокольный endpoint; анонимный browser GET не является health check. Witness усиливает обнаружение rollback, но сам по себе не создаёт консенсус, quorum или finality.

Проверенное production-развёртывание — 14 июля 2026 года

У одного production-координатора настроены три явно закреплённых оператором witness ID. Два независимо управляемых и проверенных follower-узла теперь поддерживают совместимый checkpoint service; каждый узел проверил и сохранил одну и ту же историю из 33 блоков и 8 339 обязательств. Координатор принял отдельные подписанные ответы converged от обоих follower-узлов и только после этого включил commitment_witness_startup_required = true.

При проверенном перезапуске startup guard сообщил configured=3, eligible=3, attempted=3, verified=2 и converged=2; UDP- и TUN-listener были открыты только после успешной проверки. Это закреплённое оператором доказательство отката, а не консенсус, quorum, финальность публичной цепочки или выполнение токенов.

Принудительный порог запуска 2-of-3 — 14 июля 2026 года

Production-координатор теперь использует commitment_witness_min_verified = 2 вместе с commitment_witness_startup_required = true. Запуск блокируется, если допустимые подписанные свидетельства получены менее чем от двух разных закреплённых witness: при нуле ответов возвращается signed_checkpoint_unavailable, при одном — signed_checkpoint_threshold_unmet. При последнем production-перезапуске два из трёх настроенных witness были проверены до открытия UDP, TUN и публичного API listener.

Это заданный оператором порог запуска, а не сетевой consensus, quorum, finality, выбор лидера или fork choice. Rust heartbeat передаёт только агрегированные поля политики и результата, включая startup_minimum_verified, без ID witness, endpoint, hash checkpoint или подписей.

Связанная спецификация протокола

Подписанный реестр обязательств и защита свидетелями

Проверка целостности MemChain AOF

Добавьте этот read-only барьер в каждое плановое обновление и перезапуск. Агрегированный вывод безопасен для автоматизации операций.

sudo aeronyx-server memchain verify-aof \
  --config /etc/aeronyx/server.toml

sudo aeronyx-server memchain verify-aof \
  --path /var/lib/aeronyx/.memchain

Приватность: Не загружайте, не вставляйте и не публикуйте сам AOF. Делитесь только агрегированным выводом verifier.

Полная граница целостности и доказательства: Подписанный реестр обязательств и защита свидетелями.

Контролируемое обслуживание Cargo build cache

Повторные сборки могут оставить десятки гигабайт воспроизводимых объектов Cargo. Единая команда оператора проверяет и освобождает место без удаления состояния протокола и без перезапуска сервиса.

1. Инвентаризация без изменения хоста

Сначала запустите read-only inventory. Он показывает старый target, изолированный build root, закрепленную версию Rust, SHA-256 защищенного binary и агрегированную емкость файловой системы.

cd /root/open/AeroNyx
./deploy/node/aeronyx-node.sh build-cache --repo-dir "$PWD"

2. Предпросмотр всех удаляемых объектов

Проверьте dry-run построчно. Для удаления нужны root и явный --yes; status и upgrade не запускают скрытую очистку.

sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --dry-run

3. Запуск подтвержденной очистки

sudo ./deploy/node/aeronyx-node.sh prune-build-cache \
  --repo-dir "$PWD" \
  --yes

При нестандартном build root задайте AERONYX_BUILD_TARGET_ROOT для всех трех команд, чтобы inventory и prune использовали один изолированный target.

Защищенная и удаляемая область

• Защищено: Сохраняются активный target/release/aeronyx-server, cache текущего toolchain/service, другие release binaries и rollback artifacts, данные протокола /var/lib/aeronyx, identity/config в /etc/aeronyx и cache других сервисов.
• Воспроизводимо: Удаляются только воспроизводимые Cargo outputs: старые debug/cross-target каталоги, deps, build, .fingerprint, incremental, .rlib, .rmeta, .d и target старых toolchain для того же сервиса.
• Защита выполнения: Перед удалением команда берет общий с install/upgrade deployment lock и проверяет соответствие systemd MainPID защищенному binary. Hash вычисляется до и после; изменение приводит к ошибке.

Проверка после обслуживания

Очистка cache не перезапускает узел и не требует drain активных сессий. После нее проверьте service health, startup readiness, discovery quorum и свежесть two-hop proof.

./deploy/node/aeronyx-node.sh status --repo-dir "$PWD"
./deploy/node/aeronyx-node.sh health --repo-dir "$PWD" --json

Проверка в production — 26 июля 2026

Контролируемый запуск освободил 50,649,768 KiB; использование диска снизилось с 90% до 65%. SHA-256 binary, MainPID и число рестартов не изменились; startup остался без ошибок, two-hop proof — ready/stable.

Граница приватности: Inventory выводит только локальные пути, размеры, версию toolchain, hash binary и агрегированную емкость. Он не читает ciphertext payload, MemChain records, ключи, peer identities, routes, client addresses, DNS, назначения или social graph.

Эксплуатация необязательного cognitive worker

SuperNode cognitive worker необязателен и по умолчанию выключен. Включайте его только на обрабатывающем узле с понятной ролью доверия.

Минимальная конфигурация локального провайдера

[memchain.supernode]
enabled = true

[[memchain.supernode.providers]]
name = "local-ollama"
type = "openai_compatible"
api_base = "http://127.0.0.1:11434/v1"
api_key = ""
model = "llama3.2"
max_tokens = 1000
temperature = 0.3

[memchain.supernode.routing]
fallback = "local-ollama"

[memchain.supernode.privacy]
default_level = "structured"
allow_full_for = []

Также поддерживается api_key = "$ENV_VAR". Не храните секреты в зафиксированной конфигурации.

Формы OpenAI-совместимого endpoint

Все три формы приводят к одному Chat Completions endpoint:

• https://provider.example
• https://provider.example/v1
• https://provider.example/v1/chat/completions

Для type = "anthropic" поле api_base можно опустить; текущий runtime использует официальный Anthropic Messages endpoint.

Отказы и ресурсные пределы

• Успешный ответ ограничен 8 MiB до разбора JSON, диагностический ответ ошибки — 64 KiB.
• Ошибки транспорта, API, разбора и пустой ответ переводят провайдера в 30-секундный cooldown по монотонным часам, а не отключают навсегда.
• HTTP 429 Retry-After применяется в пределах 1-300 секунд; при отсутствии используется 30 секунд.
• Router может выбрать другого здорового провайдера и автоматически повторно рассматривает отказавший после cooldown. Фоновая задача не нужна.

Перед перезапуском выполните aeronyx-server validate -c /etc/aeronyx/server.toml. Поведение находится в текущем main; установленный узел нужно пересобрать или обновить до содержащего его релиза.

Граница приватности: узлы хранения и relay остаются node-blind. Включенный cognitive worker и внешний провайдер видят prompt, разрешенный privacy level. Оставляйте default_level = "structured" и пустой allow_full_for, если нет явного согласия на обработку полного содержимого.