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.

Exploitation des témoins épinglés

Les témoins épinglés constituent une politique de confiance explicite de l'opérateur pour le coordinateur d'engagements MemChain. Ne configurez que des followers indépendants, audités et chargés de conserver l'historique de ce coordinateur.

toml

[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

Remplacez tous les placeholders avant validation. Trois ID Ed25519 uniques, non nuls et de 32 octets au maximum sont acceptés ; ces options ne sont valides que sur le coordinateur.

Déploiement sûr : mettez à niveau au moins deux followers audités ; ajoutez leurs ID exacts avec strict désactivé ; exécutez aeronyx-server validate -c /etc/aeronyx/server.toml ; redémarrez et confirmez l'acceptation de preuves signées avec la portée operator_pinned ; n'activez strict qu'après avoir répété le test.

Sans strict, un témoin indisponible produit un avertissement degraded visible tout en préservant la disponibilité. Un remote-ahead ou divergence signé bloque toujours le démarrage. Avec strict, l'absence de preuve vérifiée le bloque également.

Checkpoint est un endpoint de protocole signé ; un GET anonyme n'est pas un health check. Les témoins renforcent la détection de rollback mais ne créent pas seuls consensus, quorum ou finalité.

Déploiement de production vérifié — 14 juillet 2026

Un coordinateur de production possède trois identités witness épinglées par l'opérateur. Deux followers exploités indépendamment et audités fournissent désormais des checkpoints compatibles ; chacun a vérifié et conservé le même historique de 33 blocs et 8 339 engagements. Le coordinateur a accepté deux réponses converged distinctes et signées, puis a activé commitment_witness_startup_required = true.

Lors du redémarrage vérifié, le startup guard a indiqué configured=3, eligible=3, attempted=3, verified=2 et converged=2 ; les listeners UDP et TUN n'ont été ouverts qu'après validation. Il s'agit d'une preuve de rollback épinglée par l'opérateur, et non d'un consensus, d'un quorum, de la finalité d'une chaîne publique ou d'une exécution de jetons.

Seuil de démarrage 2-of-3 appliqué — 14 juillet 2026

Le coordinateur de production définit maintenant commitment_witness_min_verified = 2 avec commitment_witness_startup_required = true. Le démarrage est bloqué si moins de deux witnesses épinglés et distincts fournissent une preuve signée valide : aucune réponse valide produit signed_checkpoint_unavailable, une seule produit signed_checkpoint_threshold_unmet. Le dernier redémarrage de production a vérifié deux des trois witnesses configurés avant l'ouverture d'UDP, de TUN ou du listener de l'API publique.

Il s'agit d'un seuil de démarrage défini par l'opérateur, et non d'un consensus réseau, d'un quorum, d'une finalité, d'une élection de leader ou d'un fork choice. Le heartbeat Rust ne transmet que des champs agrégés de politique et de résultat, dont startup_minimum_verified, sans exposer les identités, endpoints, hash de checkpoint ou signatures.

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 /etc/aeronyx/server.toml

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

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 /root/open/AeroNyx
./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 /var/lib/aeronyx, l'identité/configuration de /etc/aeronyx 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://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" 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 /etc/aeronyx/server.toml. 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.