MemChain et stockage chiffré

« MemChain et stockage chiffré » 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 « MemChain et stockage chiffré » 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 à Nodeboard. 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.

Registre d'engagements et protection contre le retour arrière

MemChain tient un registre append-only d'engagements pour les données chiffrées. Un bloc contient des engagements d'intégrité et des métadonnées d'ordre, jamais les souvenirs en clair ni les clés de déchiffrement. Il sert à détecter l'altération et le rollback ; ce n'est pas une blockchain publique et il ne revendique ni consensus distribué, ni finalité, ni exécution de jetons.

Avant d'ouvrir UDP, TUN ou l'API publique, le coordinateur vérifie successivement le mode de durabilité, l'intégralité de la chaîne persistée, l'ancre locale signée de la pointe, les preuves de checkpoint conservées et les checkpoints signés des nœuds externes épinglés par l'opérateur.

Résultat vérifié	Décision au démarrage
Convergent	Continuer
Distant en retard	Continuer
Distant en avance	Arrêter : rollback local possible
Historique divergent	Arrêter : les historiques signés sont en conflit
Aucune preuve signée	Continuer en mode dégradé seulement sans strict ; avec strict, arrêter

Les témoins doivent être des identités Ed25519 explicitement épinglées par l'opérateur. Un peer permissionless n'obtient aucune autorité de démarrage par sa seule présence dans le peer store.

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.

Le heartbeat ne transmet que la portée, le nombre de témoins et l'exigence strict ; il n'expose ni identités, ni endpoints, ni hash, ni signatures, ni contenu chiffré, ni propriétaires, ni relations sociales.

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

Choisir son moteur et frontière du fournisseur de modèle

MemChain sépare le stockage aveugle pour le noeud du traitement cognitif optionnel. Activer un cognitive worker SuperNode ne donne pas aux noeuds de stockage ou relay la permission de lire la mémoire.

Ce que voit chaque composant

Un noeud de stockage ou relay node-blind voit le ciphertext, les blind indexes, des métadonnées de route limitées et des signaux de santé agrégés ; il ne reçoit pas la mémoire en clair par défaut.
Un cognitive worker SuperNode activé ne reçoit que le task payload autorisé par le niveau structured, summary ou full.
Un fournisseur de modèle externe peut lire le prompt exact qui lui est envoyé. N'utilisez full qu'avec un consentement explicite et un fournisseur choisi comme fiable.
Un modèle local compatible OpenAI garde l'inférence dans la frontière de l'opérateur, mais son worker reste un composant de traitement de confiance, pas un noeud de stockage aveugle.

Isolation du runtime

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.

Ces limites protègent la disponibilité du noeud, mais ne rendent pas l'inférence externe E2E. Le fournisseur externe reste une décision de confiance séparée et explicite.