Registre signé des engagements et protection par témoins

AeroNyx exploite un registre signé, append-only, d'engagements pour les enregistrements MemChain chiffrés. Il prouve l'ordre et l'intégrité, mais l'infrastructure ne peut pas lire la mémoire. Ce n'est pas une blockchain publique.

Invariant du protocole: Coordinateur, followers, témoins, backend et site ne traitent que des engagements sur ciphertext et des preuves opérationnelles limitées; ils ne reçoivent ni mémoire en clair, ni clés, ni relations de propriétaires, ni graphe social.

Architecture de production actuelle

Un coordinateur et trois noeuds follower/témoin audités sont utilisés. Le démarrage exige 2 checkpoints signés sur 3; la production en fonctionnement exige un lease court 3/3.

observed_at=2026-07-16 · reporting_nodes=4 · coordinator=1 · followers=3 · height=33 · commitments=8,339 · witness_lease=3/3.

client.encrypt_and_sign
  -> coordinator.append_opaque_commitment
  -> follower.verify_signed_ancestry
  -> pinned_witness.retain_checkpoint_and_grant_bounded_lease

Flux d'écriture et de vérification

1. Le client chiffre et signe localement un enregistrement mémoire éligible.
2. Le coordinateur ajoute uniquement l'engagement opaque et les metadata d'ordre.
3. Chaque ajout vérifie le Block signé précédent et met à jour un high-water anchor local signé.
4. Les followers récupèrent des pages limitées, vérifient ancestry et signatures et conservent les checkpoint certificates.
5. Un nouveau commitment Block n'est produit que tant que tous les runtime witnesses configurés accordent la même instance de lease court.

Contrôles au démarrage et en runtime

Deux contrôles indépendants détectent un rollback et empêchent des coordinateurs copiés de produire simultanément.

• Seuil de démarrage: Avant d'ouvrir les listeners UDP, TUN ou API, des preuves signées valides d'au moins deux witnesses distincts parmi les trois épinglés par l'opérateur sont requises.
• Lease de runtime: Les trois witnesses configurés doivent accorder un lease court au coordinateur actif. Un renouvellement partiel passe en degraded; la nouvelle production s'arrête lorsque l'autorité expire.
• Récupération: Après le retour de la connectivité, un nouveau tour complet de lease restaure l'autorité de production et incrémente le compteur agrégé de récupération.

Comportement en cas de panne

Un renouvellement partiel passe en degraded et réessaie tant que le lease existant reste valide. À expiration, la production de nouveaux engagements s'arrête. Un état remote-ahead ou des historiques signés divergents bloquent le démarrage.

renewal_degraded -> retry_until_expiry

expired -> coordinator_lease_production_permitted=false

remote_ahead | diverged -> startup_denied

Observabilité publique

L'API n'expose que des agrégats: noeuds vérifiés, hauteur tip, nombre d'engagements et état du lease. Aucun hash, signature, identité de témoin, endpoint, propriétaire ou contenu n'est publié.

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/
data.protocol_status.memory_chain

{
  "mode": "signed_commitment_ledger",
  "status": "witness_protected",
  "verified_nodes": 4,
  "coordinator_nodes": 1,
  "follower_nodes": 3,
  "max_verified_tip_height": 33,
  "max_verified_commitment_count": 8339,
  "max_granted_witnesses": 3,
  "max_required_witnesses": 3,
  "network_consensus": "not_claimed"
}

Coordinateur, followers, témoins, backend et site ne traitent que des engagements sur ciphertext et des preuves opérationnelles limitées; ils ne reçoivent ni mémoire en clair, ni clés, ni relations de propriétaires, ni graphe social.

Limite de confidentialité

Le contract central/public exclut record IDs, Block hashes, signatures, identity des witnesses, endpoints, owners, corps ciphertext, plaintext, routes, client metadata, wallet-level traffic et arêtes du social graph. Le nombre agrégé de commitments prouve le travail du système, pas le contenu d'une mémoire ni son auteur.

Ce que ce mécanisme n'est pas

• Ce n'est pas un consensus permissionless, une finalité byzantine ou un fork choice.
• Ce n'est ni un registre de tokens ni une plateforme de smart contracts.
• Il ne permet pas aux noeuds de lire la mémoire en clair.

Heartbeat

coordinator_lease_state, coordinator_lease_granted_witnesses, coordinator_lease_required_witnesses, coordinator_lease_seconds_remaining, coordinator_lease_production_permitted, coordinator_lease_last_failure_at, coordinator_lease_consecutive_failures, coordinator_lease_recoveries_total.

Questions fréquentes

AeroNyx possède-t-il maintenant des Blocks ?

Oui. Le sous-système de commitments utilise des Blocks signés pour ordonner les commitments opaques d'enregistrements chiffrés. Il ne doit pas être décrit comme une blockchain publique ni comme un réseau de consensus global.

Que se passe-t-il si un witness est hors ligne ?

Le renouvellement partiel apparaît degraded tant que l'autorité actuelle reste valide. Si le lease expire sans nouvel accord de tous les witnesses, la production de nouveaux commitments s'arrête automatiquement.

Un witness peut-il lire la mémoire MemChain ?

Non. Il vérifie la structure signée des commitments et la propriété du lease, sans recevoir de records plaintext ni de clés de déchiffrement.

Documentation associée: MemChain and Decentralized Node Operations.

Vérifier l'historique local en ajout seul

Chaque noeud décentralisé AeroNyx actuel peut inspecter son fichier MemChain append-only local sans afficher le contenu des mémoires. C'est une barrière d'intégrité locale pour redémarrage, mise à niveau, récupération mirror et analyse d'incident.

Ce que vérifie l'outil

• Un framing canonique et borné, avec 10 MiB maximum par record décodé.
• Chaque Fact autonome et chaque Fact d'un Block correspond à son fact_id dérivé du contenu.
• Le Merkle root de chaque Block correspond à l'ordre exact des identifiants Fact stockés.
• Les Block consécutifs préservent la continuité de height et le lien previous-Block hash.
• Le fichier se termine à la limite d'un record complet; une queue physique incomplète est signalée séparément.

Commande en lecture seule

Exécutez-la sur le chemin configuré ou indiquez un chemin explicite:

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

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

Barrière de mise à niveau et de récupération

1. Exécutez verify-aof avant de remplacer le binary et conservez le résultat agrégé dans le command audit.
2. Validez le nouveau binary et effectuez le même scan en lecture seule avant de redémarrer le service.
3. Après redémarrage, confirmez que replay a restauré la même height ou une valeur supérieure, puis lancez les health checks.
4. Si un record complet échoue à la validation sémantique, arrêtez et conservez les preuves; ne tronquez ni ne fusionnez automatiquement.

Limite de la preuve

La commande affiche seulement le chemin et des compteurs agrégés. Elle n'affiche jamais valeurs Fact, record ID, Block hash, signatures, propriétaires, witness identity, endpoints, routes ou clés. Un Mirror ou Full node peut valider indépendamment les mêmes octets après synchronisation sans connaître la mémoire chiffrée.

Ce scan ne remplace pas la validation des signatures Block, les witness certificates, runtime leases, fork choice ou consensus. Un AOF propre prouve l'intégrité structurelle locale, pas l'honnêteté universelle.

Chemins d'implémentation:

• crates/aeronyx-server/src/services/memchain/aof.rs
• crates/aeronyx-server/src/main.rs