Exploitation des noeuds de confidentialité décentralisés

« Exploitation et contrôles de santé des noeuds de confidentialité décentralisés » est une page localisée officielle de la documentation AeroNyx. AeroNyx sépare la couche protocolaire de l'expérience produit : le protocole fournit des capacités ouvertes et résilientes, tandis que l'App, Nodeboard, le chat chiffré, le stockage chiffré et l'exploitation des noeuds forment l'expérience utilisateur.

Aperçu

Cette page explique en français le rôle de « Exploitation et contrôles de santé des noeuds de confidentialité décentralisés » dans le protocole ouvert de confidentialité AeroNyx, son périmètre actuel, ses invariants de confidentialité et les notes de développement et d'exploitation.

Place dans l'architecture AeroNyx

Ce sujet appartient à Opérateurs de noeuds. Il faut comprendre AeroNyx non comme un service centralisé unique, mais comme un ensemble de capacités de protocole partagées par les clients, les noeuds de confidentialité décentralisés, les coordinateurs backend et Nodeboard.

Points clés d'implémentation

Toute capacité liée au contenu utilisateur doit circuler sous forme de chiffrement de bout en bout ou d'objet chiffré.
Les noeuds de confidentialité décentralisés peuvent rapporter santé, capacité, connexions, preuves de route et statistiques agrégées, mais ne doivent pas lire les messages, identifiants d'accès ou secrets utilisateur.
Nodeboard fournit l'observabilité opérationnelle : santé du noeud, peer discovery, reprise après redémarrage, capacité, paquets/trafic et état du protocole.
Aujourd'hui le backend coordonne, ordonne, agrège et expose les API publiques de documentation ; certaines responsabilités pourront migrer vers la couche Rust.

Frontière de confidentialité

L'invariant central d'AeroNyx est le blind-node invariant : les noeuds relay et les coordinateurs MemChain ne traitent que ciphertext, horodatages, preuves, signaux de santé agrégés et métadonnées de routage limitées. Ils ne doivent pas lire le clair, le DNS, les destinations ni reconstruire les relations sociales.

Points à surveiller pour les opérateurs

L'opérateur doit suivre bande passante, limites de connexion, pool IP, conntrack, descripteurs de fichier, packet drops, pps, bps, peer store, fraîcheur heartbeat et restart recovery. L'interface doit aider au diagnostic sans exposer de contenu utilisateur ni de données corrélables.

Intégration développeur et produit

Clients, App, AI agents et services tiers doivent réutiliser l'enveloppe chiffrée, les signatures, le blind relay, les identifiants anonymes et les healthchecks AeroNyx. Toute nouvelle API doit distinguer les métadonnées publiques des champs qui restent dans le E2E payload.

État actuel

Cette page décrit la frontière publique actuelle du protocole et du produit AeroNyx. multi-hop routing, blind-signed vouchers, encrypted media blob, synchronisation MemChain et évolutions node discovery doivent rester maintenus sous le même translation_key.

Spécification associée

Registre signé des engagements et protection par témoins

Contrôle d'intégrité MemChain AOF

Ajoutez cette barrière en lecture seule à chaque mise à niveau et redémarrage planifiés. Sa sortie agrégée convient à l'automatisation opérationnelle.

bash

sudo aeronyx-server memchain verify-aof \
  --config <node-config>

sudo aeronyx-server memchain verify-aof \
  --path <node-state>

Résultat	Action opérateur
`status: verified` et `torn_tail_bytes: 0`	Poursuivez la validation de configuration et le guarded restart.
`torn_tail_detected`	Ne modifiez pas le fichier. Seul guarded append-open peut retirer la queue physique incomplète après un scan sémantique complet.
Erreur d'intégrité	Arrêtez. Conservez AOF et logs pour l'analyse; la corruption sémantique d'un record complet échoue de manière fermée.

Confidentialité: Ne téléversez, collez ou publiez jamais l'AOF. Partagez seulement la sortie agrégée du verifier.

Limite complète d'intégrité et de preuve: Registre signé des engagements et protection par témoins.

Maintenance contrôlée du cache de compilation Cargo

Des compilations répétées peuvent laisser des dizaines de Go d'objets Cargo régénérables. La commande unifiée inspecte et récupère l'espace sans supprimer l'état du protocole ni redémarrer le service.

1. Inventaire sans modifier l'hôte

Exécutez d'abord l'inventaire en lecture seule. Il affiche l'ancien target, le build root isolé, la version Rust épinglée, le SHA-256 du binaire protégé et la capacité agrégée du système de fichiers.

bash

cd <node-repository>
./deploy/node/aeronyx-node.sh build-cache --repo-dir "$PWD"

2. Prévisualisation de chaque élément supprimable

Vérifiez le dry-run ligne par ligne. La suppression exige root et un --yes explicite ; status et upgrade ne déclenchent aucun nettoyage implicite.

bash

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

3. Exécution du nettoyage confirmé

bash

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

Avec un build root personnalisé, exportez AERONYX_BUILD_TARGET_ROOT pour les trois commandes afin que l'inventaire et le nettoyage utilisent le même target isolé.

Périmètre protégé et supprimable

Protégé: La commande conserve target/release/aeronyx-server, le cache toolchain/service actuel, les autres exécutables release et rollback artifacts, les données protocole de <node-state>, l'identité/configuration de <node-config-directory> et les caches des autres services.
Régénérable: Elle supprime seulement les sorties Cargo régénérables : anciens répertoires debug/cross-target, deps, build, .fingerprint, incremental, .rlib, .rmeta, .d et targets d'anciens toolchains du même service.
Protection d'exécution: Avant suppression, elle prend le deployment lock partagé avec install/upgrade et vérifie que MainPID exécute le binaire protégé. Le hash est calculé avant et après ; tout changement fait échouer l'opération.

Vérification après maintenance

Le nettoyage ne redémarre pas le noeud et ne nécessite pas de drainer les sessions actives. Ensuite, confirmez service health, startup readiness, discovery quorum et la fraîcheur de la preuve à deux sauts.

bash

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

Preuve de validation en production — 26 juillet 2026

Une exécution contrôlée a récupéré 50,649,768 KiB ; l'utilisation est passée de 90 % à 65 %. SHA-256, MainPID et nombre de redémarrages sont restés identiques ; startup sans échec et preuve à deux sauts ready/stable.

Frontière de confidentialité: L'inventaire affiche uniquement chemins locaux, tailles, version toolchain, hash du binaire et capacité agrégée. Il ne lit ni payload chiffré, record MemChain, clé, identité peer, route, adresse client, DNS, destination ou graphe social.

Exploitation du cognitive worker optionnel

Le cognitive worker SuperNode est optionnel et désactivé par défaut. Activez-le seulement sur un noeud de traitement dont le rôle de confiance est compris.

Configuration minimale d'un fournisseur local

toml

[memchain.supernode]
enabled = true

[[memchain.supernode.providers]]
name = "local-ollama"
type = "openai_compatible"
api_base = "http://localhost: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" est également pris en charge. Ne placez pas de secrets dans une configuration versionnée.

Formes d'endpoint compatibles OpenAI

Les trois formes aboutissent au même endpoint Chat Completions :

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

Pour type = "anthropic", api_base peut être omis ; le runtime actuel utilise l'endpoint officiel Anthropic Messages.

Échecs et limites de ressources

Une réponse réussie est limitée à 8 MiB avant analyse JSON ; un corps de diagnostic d'erreur est limité à 64 KiB.
Les erreurs de transport, API, parsing ou réponse vide placent le fournisseur en cooldown monotone de 30 secondes au lieu de le désactiver définitivement.
HTTP 429 Retry-After est respecté entre 1 et 300 secondes ; en son absence, 30 secondes sont utilisées.
Le router peut utiliser un autre fournisseur sain et réévalue automatiquement le fournisseur en échec après le cooldown. Aucune tâche planifiée n'est requise.

Avant redémarrage, exécutez aeronyx-server validate -c <node-config>. Ce comportement est dans le main actuel ; un noeud installé doit être recompilé ou mis à niveau vers une version qui l'inclut.

Frontière de confidentialité : les noeuds de stockage et relay restent node-blind. Le cognitive worker activé et tout fournisseur externe voient le prompt autorisé par le niveau de confidentialité. Conservez default_level = "structured" et laissez allow_full_for vide sans consentement explicite pour le contenu complet.