oc-discovery/docs/NOTE_DIVERGENCE_SYSTEME_REFERENCE.md

# Note de Divergence : Proposition Architecturale vs État du Système de Référence

**Type** : Note de travail interne — analyse des écarts et feuille de route
**Version** : 1.0 — Mars 2026
**Relation** : Ce document est le complément opérationnel du document `PROPOSITION_ARCHITECTURE_MINIMALE.md` et de `COMPARAISON_SYSTEMES_ET_PROPOSITION.md`. Il ne constitue pas une étude scientifique indépendante mais un outil d'aide à la décision pour l'équipe de développement.

> **Convention** : Le terme "système de référence" désigne le système P2P de découverte et d'échange de ressources actuellement en développement, dont l'architecture de découverte est partiellement alignée avec la proposition mais qui n'implémente pas encore les couches de règlement monétaire, de confidentialité renforcée, ni les adaptations DTN. La "proposition" renvoie au document `PROPOSITION_ARCHITECTURE_MINIMALE.md`.

---

## Résumé Exécutif

| # | Gap | Criticité | Effort estimé | Priorité |
|---|---|---|---|---|
| G1 | Couche blockchain de règlement monétaire absente | 🔴 Critique | Élevé (6–12 mois) | P0 |
| G2 | Records DHT non chiffrés (confidentialité payload) | 🔴 Critique (contexte hostile) | Faible (2–4 semaines) | P1 |
| G3 | Absence de tolérance DTN | 🔴 Critique (contexte spatial) | Moyen (2–4 mois) | P1 |
| G4 | Gestion de consortiums binaire (absence du niveau 2) | 🟠 Significatif | Moyen (1–3 mois) | P2 |
| G5 | Résistance Sybil uniquement organisationnelle | 🟠 Significatif (réseau ouvert) | Dépend de G1 | P3 |
| G6 | Attestation ZK de consommation absente | 🟠 Significatif | Élevé (4–8 mois) | P2 |
| G7 | Identité DID non implémentée | 🟡 Partiel | Moyen (2–3 mois) | P3 |
| G8 | Scoring multidimensionnel | ✅ Convergence forte | — | — |
| G9 | Gossip / SWIM membership events | ✅ Convergence forte | — | — |

**Lecture** : Les gaps G1, G2, G3 sont bloquants pour un déploiement en contexte hostile ou spatial. G4 et G6 sont nécessaires pour la marketplace de ressources. G5 et G7 sont des améliorations importantes mais non bloquantes à court terme pour les déploiements en réseau fermé.

---

## Contexte : Deux Systèmes à Prérequis Distincts

La proposition distingue formellement deux sous-systèmes aux prérequis mutuellement incompatibles s'ils étaient fusionnés :

### Système de Découverte et d'Échange entre Pairs
**Rôle** : localiser les pairs, évaluer leur qualité, maintenir le réseau de voisinage, propager les enregistrements de ressources.

**Prérequis** :
- Haute disponibilité (profil AP du théorème CAP)
- Tolérance aux partitions et à la connectivité intermittente
- Faible latence de découverte (secondes, pas minutes)
- Cohérence éventuelle acceptable
- Protocoles légers, binaires, compacts

**Ce que le système de référence implémente** : ce sous-système est substantiellement développé. La DHT Kademlia, le scoring multidimensionnel, les heartbeats bidirectionnels, le gossip d'événements d'appartenance, et la ConnectionGater sont en place et alignés avec la proposition.

### Système de Règlement Monétaire et Transactionnel
**Rôle** : régler les transactions financières résultant de la consommation de ressources marketplace (compute, stockage, données, workflows), de manière automatisée et confidentielle.

**Prérequis** :
- Cohérence forte (profil CP — prévention double-spend)
- Finalité déterministe ou quasi-déterministe
- Confidentialité des montants et des parties
- Smart contracts pour l'automatisation du paiement conditionnel
- Gouvernance de consortium (admission, révocation de validateurs)
- Faible empreinte énergétique (PoW exclu)

**Ce que le système de référence implémente** : ce sous-système est entièrement absent. C'est le gap le plus critique.

> **Principe fondamental** : ces deux systèmes NE DOIVENT PAS partager le même protocole. La découverte optimise pour la disponibilité — la blockchain optimise pour la cohérence. Fusionner ces couches dégrade les garanties des deux.

---

## G1 — Couche Blockchain de Règlement Monétaire Absente

**Criticité** : 🔴 Critique — bloquant pour la marketplace économique

### État actuel du système de référence
Le système de référence ne dispose d'aucune couche de règlement monétaire. Il peut découvrir des ressources, coordonner leur utilisation, et propager des records de présence, mais ne peut pas :
- Automatiser le paiement entre fournisseur et consommateur de ressources
- Émettre un token ou représenter une unité de valeur
- Exécuter un contrat conditionnel à l'attestation d'une livraison de ressource
- Régler des transactions entre organisations différentes sans accord hors-bande

### Impact opérationnel
Sans couche de règlement, la marketplace de ressources (compute, storage, data, workflows en rent/buy) ne peut fonctionner qu'avec des accords commerciaux hors-bande — ce qui annule le bénéfice de la décentralisation pour l'aspect économique. Un fournisseur de compute ne peut pas être payé automatiquement à la livraison d'un résultat vérifié.

### Options de développement

**Option A — Hyperledger Fabric (recommandée pour phase 1)**
- Blockchain permissionnée, consortium fermé
- Finalité déterministe (Raft ou PBFT), canaux privés natifs
- Chaincode Go/Node.js mature, CouchDB state store
- Aucun token public requis : jeton interne au consortium
- **Avantage** : maturité maximale, documentation, écosystème d'entreprise
- **Inconvénient** : pas trustless pour les échanges inter-consortium
- **Effort** : 3–6 mois pour une intégration fonctionnelle

**Option B — Cosmos SDK + zone permissionnée (recommandée si interopérabilité inter-consortium est prioritaire)**
- Chaîne souveraine Cosmos, consensus Tendermint BFT (~6s finalité)
- IBC pour les échanges inter-zone (inter-consortium)
- CosmWasm pour les smart contracts
- **Avantage** : interopérabilité native avec d'autres zones Cosmos
- **Inconvénient** : pas de confidentialité native inter-zone, complexity opérationnelle plus élevée que Fabric
- **Effort** : 4–8 mois pour une intégration fonctionnelle

**Option C — Secret Network + Cosmos (recommandée pour inter-consortium confidentiel)**
- Smart contracts chiffrés via TEE (Intel SGX)
- Compatible Cosmos (IBC), finalité Tendermint
- **Avantage** : confidentialité des smart contracts native
- **Inconvénient** : dépendance SGX (side-channels documentés), écosystème plus restreint
- **Usage recommandé** : couche inter-consortium après phase 1 avec Fabric intra-consortium

**Option D — Oasis Network (alternative à Secret pour environnements embarqués)**
- ParaTime confidentielle + EVM (Sapphire)
- Compatible Cosmos
- **Avantage** : EVM mature + confidentialité, architecture ParaTime flexible
- **Inconvénient** : dépendance TEE, écosystème plus jeune

### Recommandation de feuille de route pour G1
```
Phase 1 (priorité immédiate) :
  → Hyperledger Fabric intra-consortium
  → Smart contracts de paiement conditionnel basiques (attestation → paiement)
  → Interface entre le système de découverte et Fabric (événements de consommation)

Phase 2 (6–12 mois) :
  → Cosmos SDK zone permissionnée pour l'interopérabilité inter-consortium
  → IBC configuré entre les zones des différents consortiums

Phase 3 (12–24 mois) :
  → Secret Network ou Oasis pour le règlement confidentiel inter-consortium
  → ZK-proofs d'attestation de consommation (voir G6)
```

### Dépendances
- G6 (attestation ZK) dépend de G1 : impossible d'implémenter la preuve de consommation sans smart contract récepteur
- G5 (résistance Sybil cryptoéconomique) dépend de G1 : le stake on-chain requiert une blockchain

---

## G2 — Records DHT Non Chiffrés (Confidentialité du Payload)

**Criticité** : 🔴 Critique en contexte hostile — 🟡 Mineur en réseau privé fermé

### État actuel du système de référence
Les enregistrements de présence (PeerRecords) dans la DHT sont signés (authentification et intégrité garanties) mais non chiffrés. Le contenu — nom du pair, URL d'API, adresses réseau, clé publique, ressources annoncées — est lisible par tout nœud participant à la DHT ou observant le trafic réseau.

### Impact opérationnel
Dans un contexte hostile avec des watchers passifs :
- Un adversaire peut reconstruire la liste complète des participants actifs
- Les patterns d'activité (fréquence de renouvellement des records) révèlent des informations opérationnelles
- Les URLs d'API et adresses réseau permettent le ciblage d'acteurs spécifiques
- La corrélation des records dans le temps permet de reconstruire des graphes d'activité

### Options de développement

**Option A — Chiffrement symétrique par clé de consortium (recommandée)**
- La clé de déchiffrement est dérivée de la PSK du consortium
- Le payload du PeerRecord est chiffré avec AES-256-GCM avant insertion dans la DHT
- Seuls les membres partageant la PSK peuvent déchiffrer les records
- La DHT agit comme système de stockage aveugle
- **Effort** : 2–4 semaines (modification du format du PeerRecord + handlers d'encodage/décodage)

**Option B — Chiffrement asymétrique par liste d'accès (plus flexible, plus complexe)**
- Chaque record est chiffré avec les clés publiques des membres autorisés
- Permet un contrôle d'accès granulaire par record
- **Inconvénient** : taille des records augmente avec le nombre de destinataires, complexité opérationnelle

**Option C — Mode mixte : metadata publiques, payload chiffré**
- Seul le payload sensible est chiffré ; les métadonnées de routage restent en clair
- Compromis entre découvrabilité et confidentialité

### Recommandation
Option A pour les déploiements en contexte hostile. Activable par flag de configuration du réseau (backward-compatible avec les déploiements existants en réseau ouvert). Le chiffrement est transparent pour la couche DHT : la DHT stocke des opaque blobs sans connaître leur structure.

---

## G3 — Absence de Tolérance DTN

**Criticité** : 🔴 Critique pour le contexte spatial/embarqué

### État actuel du système de référence
Le système de référence est conçu pour une connectivité TCP continue :
- Heartbeats toutes les ~20 secondes — impossibles dans un contexte DTN
- Un pair absent pendant quelques intervalles est marqué suspect puis évincé
- Les scores d'uptime sont dégradés artificiellement pour les pairs à connectivité intermittente
- Aucun mécanisme de stockage-et-retransmission pour les messages non livrables
- Les TTL des PeerRecords (~2 minutes) sont inadaptés à des cycles de déconnexion de plusieurs heures

### Impact opérationnel en contexte spatial
Un satellite LEO passe hors de couverture sol toutes les 90 minutes. Avec les paramètres actuels :
- Chaque passage en dehors de couverture déclenche une série de faux positifs de détection de panne
- Le satellite est systématiquement évincé de tous les pools de ses pairs lors de chaque interruption
- À la reconnexion, une reconnexion complète (DHT bootstrap, re-heartbeat, re-scoring) est nécessaire — coûteuse en bande passante et en temps

### Options de développement

**Option A — Profil de connectivité par pair (recommandée, implémentation minimale)**
- Chaque pair déclare un profil de connectivité (`CONTINUOUS | INTERMITTENT | ORBITAL`)
- Les seuils de détection de panne sont paramétrés par profil
- Un pair `INTERMITTENT` peut être absent N heures sans déclencher de suspect
- **Effort** : 3–6 semaines (extension du PeerRecord + modification du scoring uptime)

**Option B — TTL adaptatifs selon profil orbital (complémentaire)**
- Les PeerRecords d'un pair orbital ont un TTL égal à (durée max d'absence prévisible + marge)
- Le pair renouvelle ses records juste avant chaque période de déconnexion prévue
- **Effort** : 1–2 semaines

**Option C — Heartbeats batch signés (pour le contexte DTN strict)**
- Pendant les périodes de déconnexion, les heartbeats sont signés localement avec timestamp
- À la reconnexion, ils sont soumis en batch avec validation de la séquence temporelle
- Permet une reconstruction de l'historique d'uptime sans connexion continue
- **Effort** : 4–8 semaines

**Option D — Store-and-forward pour les messages critiques**
- Les messages de mise à jour non livrables sont stockés localement et retransmis lors de la prochaine fenêtre
- Aligné avec RFC 4838 [Cerf et al., 2007]
- **Effort** : 2–4 mois (infrastructure significative)

### Recommandation
Implémenter A + B en priorité (effort faible, impact immédiat). C et D constituent une roadmap long terme pour un support DTN complet.

---

## G4 — Gestion de Consortiums Binaire (Absence du Niveau 2)

**Criticité** : 🟠 Significatif pour les coalitions multi-organisations

### État actuel du système de référence
Le système de référence implémente un modèle binaire : une PSK est présente ou absente. Un pair soit appartient au consortium (PSK correcte → confiance élevée), soit est un inconnu (pas de PSK → confiance nulle). Il n'existe pas de niveau intermédiaire formalisé pour les pairs d'organisations alliées qui ne partageraient pas la PSK principale.

### Impact opérationnel
Dans une coalition GARDEN multi-organisationnelle :
- Deux organisations alliées souhaitant interopérer doivent soit partager leur PSK principale (sécurité dégradée), soit se traiter mutuellement comme des inconnus (fonctionnalité dégradée)
- Aucun mécanisme ne permet de dire "ce pair est de confiance modérée, il peut consommer des ressources publiques mais pas les ressources critiques"

### Option de développement

**Attestation de niveau 2 (recommandée)**
- Un pair de niveau 1 (PSK) émet une attestation signée pour un pair externe
- L'attestation contient : clé publique du pair, période de validité, droits d'accès (périmètre restreint)
- Les pairs recevant une attestation valide signée par un membre de niveau 1 leur accordent un score initial de 40/100 (niveau 2)
- Les attestations sont révocables via tombstone signé
- **Effort** : 4–8 semaines (nouveau type de record + handlers d'admission)

---

## G5 — Résistance Sybil Uniquement Organisationnelle

**Criticité** : 🟠 Significatif pour les déploiements en réseau ouvert ou hostile — 🟢 Acceptable pour les consortiums fermés

### État actuel du système de référence
La PSK organisationnelle constitue une barrière d'entrée sociale efficace pour les réseaux fermés. Elle n'est pas cryptoéconomique (pas de coût financier d'entrée) mais organisationnelle (la PSK doit être obtenue auprès d'un membre existant).

### Impact
Pour les déploiements en réseau fermé (consortium PSK), ce gap n'est pas critique. Pour les déploiements en réseau ouvert ou dans des contextes où la PSK pourrait être compromise/partagée massivement, la résistance Sybil devient insuffisante.

### Option de développement
- **Stake on-chain** (dépend de G1) : exiger un dépôt de tokens sur la blockchain comme condition d'admission. Coûteux à implémenter sans G1.
- **Proof of Work sur le NodeID** (S/Kademlia style [Baumgart & Meinert, 2007]) : coût computationnel modéré à la création d'identité. Indépendant de G1. **Effort** : 2–3 semaines.

---

## G6 — Attestation ZK de Consommation de Ressource Absente

**Criticité** : 🟠 Significatif — nécessaire pour un marché de ressources décentralisé crédible

### État actuel du système de référence
Aucun mécanisme ne permet de prouver cryptographiquement qu'une ressource a été réellement consommée (compute exécuté, données livrées, stockage maintenu) sans révéler le contenu ni l'identité de l'initiateur. Le règlement des transactions repose entièrement sur la confiance organisationnelle.

### Options de développement

**Option A — TEE attestations (Intel SGX / ARM TrustZone)**
- Le nœud fournisseur exécute le workload dans une enclave sécurisée
- L'enclave génère une attestation signée par le microprocesseur prouvant que le code s'est exécuté dans un environnement sécurisé
- L'attestation est soumise au smart contract comme preuve de livraison
- **Avantage** : relativement mature (iExec utilise cette approche)
- **Inconvénient** : dépendance matérielle, vulnérabilités SGX documentées [Costan & Devadas, 2016]
- **Effort** : 3–6 mois

**Option B — ZK-proof d'exécution (approche cryptographique pure)**
- Un ZKP prouve la bonne exécution d'un programme sur des entrées données
- Pas de dépendance matérielle — sécurité cryptographique pure
- **Inconvénient** : génération du proof encore coûteuse pour des programmes complexes (zkEVM, zkVM)
- **Horizon** : viable à moyen terme (2–3 ans) pour des workloads standards

**Option C — Challenge-response statistique (approche hybride à court terme)**
- Le consommateur soumet un échantillon aléatoire de résultats intermédiaires vérifiables
- Le fournisseur prouve avoir exécuté le calcul en répondant correctement aux challenges
- Moins fort cryptographiquement mais praticable immédiatement
- **Effort** : 4–6 semaines

### Recommandation
Option C comme solution court terme (praticable sans G1 finalisé). Option A comme solution moyen terme (dépend de la disponibilité TEE sur les nœuds cibles). Option B comme horizon long terme.

---

## G7 — Identité DID Non Implémentée

**Criticité** : 🟡 Partiel — identités auto-certifiées présentes, DID formelles absentes

### État actuel du système de référence
Le système de référence utilise des identités auto-certifiées (PeerID = hash de la clé publique Ed25519) — aligné avec le principe de base de la proposition. Cependant, les DID W3C [W3C, 2022] formelles ne sont pas implémentées, ce qui limite l'interopérabilité avec les écosystèmes tiers qui utilisent ce standard.

### Impact
Pour les déploiements intra-consortium, ce gap est mineur. Pour l'interopérabilité avec des systèmes tiers (identity federations, portabilité des identités entre déploiements), l'absence de DID formelles est un frein.

### Option de développement
- Wrapper DID W3C sur les identités PeerID existantes : publier les clés publiques des pairs sous format DID document dans la DHT. **Effort** : 2–4 semaines.

---

## G8 et G9 — Points de Convergence Forts

### G8 — Scoring Multidimensionnel ✅

Le système de référence implémente un scoring à 7+ dimensions aligné avec la proposition :
- Ratio d'uptime (gap-aware : les absences courtes ne pénalisent pas)
- Latence normalisée (probe RTT)
- Précision des challenges (bandwidth + identity challenges)
- Diversité réseau (/24 subnet diversity)
- Taux de remplissage
- Cohérence des témoins (witness queries)
- Seuil d'éviction dynamique selon l'âge (20% → 80% sur 24h)

**Évaluation** : c'est la contribution la plus mature et la plus originale du système de référence. L'alignement avec la proposition est substantiel et constitue une base solide.

### G9 — Gossip / SWIM Membership Events ✅

Le système de référence implémente une propagation épidémique infection-style pour les événements d'appartenance :
- États suspects (SuspectedAt) avec incarnation numérotée
- Refutation automatique (un pair se défendant incrémente son incarnation)
- HopsLeft décroissant pour limiter la propagation des événements périmés
- Déduplication par (PeerID, Incarnation)

**Évaluation** : convergence forte avec les principes SWIM [Das et al., 2002]. L'implémentation est un atout majeur pour la résistance aux faux positifs de détection de panne.

---

## Matrice des Dépendances

```
G1 (blockchain)
  ├── G5 (stake Sybil)        — G5 dépend de G1 pour la version cryptoéconomique
  └── G6 (attestation ZK)     — G6 (option A/B) dépend de G1 pour le smart contract récepteur

G2 (chiffrement records)     — indépendant, priorité P1
G3 (DTN)                     — indépendant, priorité P1
G4 (consortiums niveau 2)    — indépendant de G1 (attestation = records signés, pas blockchain)
G7 (DID)                     — indépendant
```

---

## Roadmap de Convergence Recommandée

### Phase 0 — Fondations (immédiat, effort faible)
| Action | Gap | Durée estimée |
|---|---|---|
| Chiffrement optionnel payload DHT (clé dérivée de la PSK) | G2 | 2–4 semaines |
| Profil de connectivité par pair (CONTINUOUS/INTERMITTENT/ORBITAL) + TTL adaptatifs | G3 (partiel) | 3–6 semaines |
| Mécanisme d'attestation de niveau 2 (confiance intermédiaire) | G4 | 4–8 semaines |

### Phase 1 — Règlement Monétaire Intra-Consortium (3–6 mois)
| Action | Gap | Durée estimée |
|---|---|---|
| Intégration Hyperledger Fabric | G1 | 3–6 mois |
| Smart contracts de paiement conditionnel basiques | G1 | Inclus |
| Interface système de découverte ↔ Fabric (événements de consommation) | G1 | Inclus |
| Challenge-response statistique pour attestation de livraison | G6 (option C) | 4–6 semaines |

### Phase 2 — Règlement Inter-Consortium et Confidentialité (6–12 mois)
| Action | Gap | Durée estimée |
|---|---|---|
| Cosmos SDK zone permissionnée pour interopérabilité inter-consortium | G1 | 4–8 mois |
| Heartbeats batch signés (DTN complet) | G3 (complet) | 4–8 semaines |
| Proof of Work sur NodeID (résistance Sybil légère) | G5 | 2–3 semaines |
| Wrapper DID W3C | G7 | 2–4 semaines |

### Phase 3 — Confidentialité Transactionnelle Avancée (12–24 mois)
| Action | Gap | Durée estimée |
|---|---|---|
| Secret Network ou Oasis pour règlement confidentiel inter-consortium | G1 | 4–8 mois |
| TEE attestations pour preuve de consommation | G6 (option A) | 3–6 mois |
| Store-and-forward DTN complet (RFC 4838) | G3 (complet) | 2–4 mois |

---

## Synthèse

Le système de référence constitue une base solide pour le plan de découverte (G8, G9 convergents). Le scoring comportemental multidimensionnel et les mécanismes SWIM sont des contributions de qualité, correctement alignées avec la proposition.

Le gap structurel majeur est l'absence du plan de règlement monétaire (G1). Sans cette couche, le système peut coordonner l'utilisation de ressources mais ne peut pas les monétiser, limitant son périmètre à des usages intra-organisationnels sans incitation économique automatisée.

Les gaps de confidentialité (G2, G3) sont adressables à court terme avec un effort relativement faible et constituent des priorités immédiates pour les déploiements en contexte hostile ou spatial.

La feuille de route recommandée priorise : confidentialité immédiate (G2) → tolérance DTN partielle (G3) → règlement monétaire intra-consortium (G1, phase 1) → interopérabilité inter-consortium (G1, phase 2) → confidentialité transactionnelle avancée (G1, phase 3).

---

## Références

**[Baumgart & Meinert, 2007]** Baumgart, I., & Meinert, S. (2007). S/Kademlia: A practicable approach towards secure key-based routing. *ICPADS 2007*, pp. 1–8.

**[Cerf et al., 2007]** Cerf, V., et al. (2007). Delay-Tolerant Networking Architecture. *RFC 4838*, IETF.

**[Costan & Devadas, 2016]** Costan, V., & Devadas, S. (2016). Intel SGX Explained. *IACR Cryptology ePrint Archive*, Report 2016/086.

**[Das et al., 2002]** Das, A., Gupta, I., & Motivala, A. (2002). SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol. *DSN 2002*, pp. 303–312.

**[Douceur, 2002]** Douceur, J. R. (2002). The Sybil Attack. *IPTPS 2002*, LNCS 2429, pp. 251–260.

**[Kwon & Buchman, 2016]** Kwon, J., & Buchman, E. (2016). *Cosmos: A Network of Distributed Ledgers*. Whitepaper.

**[Oasis Labs, 2020]** Oasis Network (2020). *Oasis Network Primer*. https://oasisprotocol.org/primer

**[W3C, 2022]** W3C (2022). *Decentralized Identifiers (DIDs) v1.0*. https://www.w3.org/TR/did-core/