Discovery Neo Oclib

docs/COMPARAISON_SYSTEMES_ET_PROPOSITION.md

@@ -1,39 +1,37 @@
 # Comparaison entre les Systèmes Existants et la Proposition d'Architecture Décentralisée Souveraine
 
-**Catégorie** : Systèmes distribués — Revue comparative et positionnement architectural
+**Catégorie** : Systèmes distribués, Revue comparative et positionnement architectural
 **Domaine d'application** : Systèmes embarqués, contexte spatial, réseaux hostiles, marchés de ressources décentralisés
-**Version** : 1.1 — Mars 2026
+**Version** : 1.2, Mai 2026
 
 ---
 
 ## Résumé
 
-Ce document présente une analyse comparative systématique entre les principaux systèmes décentralisés existants — de la découverte P2P aux blockchains — et la proposition d'architecture pour un réseau décentralisé souverain opérant dans un contexte embarqué et hostile (désignée ci-après "la proposition"). Le contexte de référence est celui du projet GARDEN (Generic Architecture for Resilient Decentralized Execution Networks), qui requiert une combinaison de propriétés rarement satisfaites simultanément par un système unique : découverte décentralisée de pairs, souveraineté des données, confidentialité transactionnelle, tolérance aux disruptions réseau (DTN), et gestion de consortiums à niveaux de confiance hétérogènes.
+Ce document présente une analyse comparative entre les principaux systèmes décentralisés existants et la proposition d'architecture pour un réseau décentralisé souverain opérant dans un contexte embarqué et hostile (désignée ci-après "la proposition"). Le contexte de référence est celui du projet GARDEN (Generic Architecture for Resilient Decentralized Execution Networks), qui requiert une combinaison de propriétés rarement satisfaites simultanément : découverte décentralisée de pairs, souveraineté des données, confidentialité transactionnelle, tolérance aux disruptions réseau (DTN), et gestion de consortiums à niveaux de confiance hétérogènes.
 
-L'analyse montre qu'aucun système existant ne répond simultanément à l'ensemble de ces exigences. IPFS/libp2p offre une découverte décentralisée mature mais sans confidentialité native. Hyperledger Fabric offre une blockchain de consortium avec canaux privés mais suppose une connectivité continue. Secret Network offre des smart contracts confidentiels mais repose sur une dépendance matérielle (Intel SGX). Les systèmes de marketplace décentralisée (Golem, Akash) fournissent des mécanismes de marché mais n'abordent pas la tolérance DTN ni la gestion de la confiance relative.
+L'analyse montre qu'aucun système existant ne répond simultanément à l'ensemble de ces exigences. IPFS/libp2p offre une découverte décentralisée mature mais sans confidentialité native. Hyperledger Fabric offre une blockchain de consortium avec canaux privés mais suppose une connectivité continue. Secret Network offre des smart contracts confidentiels mais repose sur une dépendance matérielle (Intel SGX). Les systèmes de marketplace décentralisée (Golem, Akash) fournissent des mécanismes de marché mais n'adressent ni la tolérance DTN ni la confiance relative.
 
-La proposition se distingue en intégrant des mécanismes issus de plusieurs domaines de la littérature : scoring comportemental multidimensionnel inspiré des protocoles SWIM [Das et al., 2002], architecture blockchain hybride combinant blockchain permissionnée intra-consortium et règlement confidentiel inter-consortium, et adaptations DTN dérivées de la RFC 4838 [Cerf et al., 2007]. Cette synthèse architecturale constitue une contribution originale par rapport à l'existant.
+Un point structurant de la proposition est la **séparation explicite entre le système de découverte P2P** (profil AP, haute disponibilité, cohérence éventuelle) et le **système de règlement monétaire** (profil CP, cohérence forte, finalité déterministe). Ces deux sous-systèmes ont des prérequis mutuellement incompatibles : leur fusion dans un protocole unique dégraderait les garanties des deux.
 
-Un point structurant de la proposition, absent de la majorité des systèmes existants, est la **séparation explicite entre le système de découverte et d'échange pair-à-pair** (profil AP, haute disponibilité, cohérence éventuelle) et le **système de règlement monétaire** (profil CP, cohérence forte, finalité déterministe). Ces deux sous-systèmes ont des prérequis mutuellement incompatibles : leur fusion dans un protocole unique dégraderait les garanties des deux. Le tableau comparatif intègre ce critère de séparation.
+Pour la couche de règlement monétaire spécifiquement, l'analyse converge vers l'écosystème Cosmos, par sa capacité à déployer des blockchains souveraines interconnectées, couplé à Secret Network pour la confidentialité transactionnelle. Cette piste est développée en section 6.4.
 
-Les divergences détaillées entre la proposition et un système de référence en cours de développement — avec criticité, options de développement, et feuille de route — sont documentées dans le fichier `NOTE_DIVERGENCE_SYSTEME_REFERENCE.md`.
+Les divergences détaillées entre la proposition et un système de référence en cours de développement sont documentées dans `NOTE_DIVERGENCE_SYSTEME_REFERENCE.md`.
 
 ---
 
 ## 1. Critères de Comparaison
 
-Les critères suivants sont retenus pour l'analyse comparative. Chaque critère est justifié par rapport aux exigences du contexte GARDEN.
-
 | Critère | Définition | Justification GARDEN |
 |---|---|---|
 | **Décentralisation** | Absence de point unique de contrôle ou de défaillance | Contexte hostile : tout point centralisé est une cible prioritaire |
 | **Confidentialité** | Opacité du contenu ET des métadonnées pour les observateurs non autorisés | Watchers passifs, acteurs adversariaux dans le réseau |
-| **Résistance Sybil** | Capacité à résister à la création massive d'identités fictives [Douceur, 2002] | Réseau potentiellement infiltré par des adversaires |
-| **Tolérance DTN** | Opérabilité sous connectivité intermittente, haute latence, partitions prolongées [Fall, 2003] | Contrainte structurelle spatiale et embarquée |
+| **Résistance Sybil** | Capacité à résister à la création massive d'identités fictives | Réseau potentiellement infiltré par des adversaires |
+| **Tolérance DTN** | Opérabilité sous connectivité intermittente, haute latence, partitions prolongées | Contrainte structurelle spatiale et embarquée |
 | **Scalabilité** | Passage à l'échelle sans dégradation prohibitive des performances | Multi-cluster, multi-organisation |
 | **Finalité des transactions** | Délai et certitude de l'irréversibilité des transactions monétaires | Prévention du double-spend dans les contextes DTN |
 | **Smart contracts** | Capacité d'automatiser le règlement conditionnel à des événements vérifiables | Marché de ressources : paiement automatique à la livraison attestée |
-| **Séparation découverte / règlement** | Architecture explicitement distincte entre la couche de découverte P2P (AP) et la couche de règlement monétaire (CP) | Prérequis mutuellement incompatibles — toute fusion dégrade les garanties des deux |
+| **Séparation découverte / règlement** | Architecture explicitement distincte entre couche P2P (AP) et couche monétaire (CP) | Prérequis mutuellement incompatibles, toute fusion dégrade les deux |
 | **Gestion de consortiums** | Mécanismes d'admission, révocation, et niveaux de confiance différenciés | Coalitions multi-organisations à confiance hétérogène |
 | **Souveraineté** | Contrôle par le créateur du cycle de vie de ses données et identités | Exigence fondamentale du contexte spatial/militaire |
 | **Maturité** | Disponibilité en production, documentation, écosystème | Faisabilité d'implémentation dans un délai raisonnable |
@@ -43,299 +41,127 @@ Les critères suivants sont retenus pour l'analyse comparative. Chaque critère
 
 ## 2. Systèmes de Découverte et Stockage P2P
 
-### 2.1 IPFS / Libp2p (Benet, 2014)
+### 2.1 IPFS / Libp2p
 
-**Principe** : IPFS (InterPlanetary File System) est un système de fichiers distribué adressé par contenu. Chaque bloc de données est identifié par son hash cryptographique (Content Identifier, CID), permettant une vérification d'intégrité intrinsèque et une déduplication automatique. La couche de découverte repose sur une DHT Kademlia publique [Maymounkov & Mazières, 2002] implémentée dans libp2p.
+IPFS (InterPlanetary File System) [3] est un système de fichiers distribué adressé par contenu : chaque bloc est identifié par son hash cryptographique (CID), ce qui garantit l'intégrité intrinsèque et la déduplication. La couche de découverte repose sur une DHT Kademlia [25] publique, implémentée dans libp2p, qui constitue probablement l'écosystème P2P le plus modulaire et le plus mature disponible aujourd'hui, transports multiples (TCP, QUIC, WebTransport), NAT traversal, multiplexage de protocoles.
 
-**Forces** :
-- Architecture décentralisée mature, déployée à très large échelle
-- Vérification d'intégrité native par adressage de contenu
-- Écosystème libp2p modulaire (transports multiples : TCP, QUIC, WebTransport, Bluetooth)
-- Comunauté active, documentation extensive
-- Support natif pour les connexions multi-transport et le NAT traversal
+Dans IPFS, la DHT est publique par construction. Tout observateur participant à la DHT peut voir quels CIDs sont recherchés et par qui, ce qui dans un contexte hostile revient à diffuser en clair quelles ressources un nœud cherche. Des couches additionnelles (DHT privée avec espace de noms isolé, chiffrement du contenu) peuvent rendre libp2p utilisable comme couche de transport, mais IPFS dans sa forme standard est inadapté. Il n'existe pas non plus de mécanisme de confiance ou de scoring des pairs : n'importe quel nœud peut rejoindre la DHT publique.
 
-**Faiblesses** :
-- Aucune confidentialité native : les CIDs dans la DHT publique révèlent quels contenus sont recherchés et partagés
-- Aucun contrôle d'accès à la couche de découverte : tout nœud peut rejoindre la DHT publique
-- Résistance Sybil non résolue dans la DHT publique
-- Pas de mécanisme de confiance ou de scoring des pairs
-- Latences de découverte incompatibles avec les contraintes DTN sévères
+libp2p reste malgré tout une référence incontournable pour la couche de transport, c'est le socle sur lequel la proposition elle-même s'appuie.
 
-**Compatibilité GARDEN** : Inadapté en l'état. La DHT publique IPFS est une source de fuite d'information massive dans un contexte hostile. Le fait qu'un ensemble de nœuds recherche des ressources de type spécifique révèle des informations stratégiques à tout observateur participant à la DHT. Des couches additionnelles de confidentialité (chiffrement du contenu, utilisation d'une DHT privée avec espace de noms isolé) peuvent rendre libp2p utilisable comme couche de transport, mais IPFS dans sa forme standard est inadapté.
+### 2.2 Filecoin
 
-### 2.2 Filecoin (Protocol Labs, 2017)
+Filecoin [32] est un marché de stockage décentralisé construit sur IPFS, où les fournisseurs s'engagent à stocker des données via des preuves cryptographiques vérifiables (Proof of Replication, Proof of Spacetime). L'idée de rémunérer le stockage par des preuves plutôt que par de la confiance est conceptuellement solide et constitue une inspiration pour la couche d'attestation de la proposition.
 
-**Principe** : Filecoin est un marché de stockage décentralisé construit sur IPFS. Les fournisseurs de stockage s'engagent à stocker des données en soumettant des preuves cryptographiques : Proof of Replication (PoRep) prouve qu'une copie unique d'un fichier est bien stockée, Proof of Spacetime (PoSt) prouve que le stockage est maintenu dans le temps. Le marché de stockage est réglé via des smart contracts sur la chaîne Filecoin.
+En revanche, les transactions on-chain Filecoin sont entièrement publiques, qui stocke quoi pour qui, à quel coût, ce qui est incompatible avec le contexte hostile. La complexité des preuves cryptographiques introduit également une charge de calcul significative, difficilement absorbable par des nœuds embarqués à ressources contraintes.
 
-**Forces** :
-- Incentives cryptoéconomiques alignant les comportements des fournisseurs avec les intérêts des utilisateurs
-- Preuves cryptographiques vérifiables de l'exécution du stockage
-- Décentralisé avec un marché libre de capacité
+### 2.3 BitTorrent DHT
 
-**Faiblesses** :
-- Transactions on-chain sur Filecoin entièrement publiques : les accords de stockage révèlent qui stocke quoi pour qui
-- Latences élevées incompatibles avec les workloads temps-réel
-- Complexité des preuves cryptographiques : charge de calcul significative pour les nœuds
-- Pas de gestion de confiance relative entre pairs ; pas de consortium
+BitTorrent DHT (BEP 5) [23] est la DHT Kademlia la plus déployée au monde, avec des centaines de millions de nœuds. Sa résilience à grande échelle est exceptionnelle et bien documentée. Pour GARDEN, c'est essentiellement une référence théorique : aucune authentification des nœuds, aucune confidentialité des requêtes, résistance Sybil nulle. Tout nœud peut annoncer n'importe quelle clé, et les requêtes révèlent immédiatement ce que le demandeur cherche.
 
-**Compatibilité GARDEN** : Le modèle de preuves cryptographiques de consommation de ressources est conceptuellement pertinent et constitue une inspiration pour la couche d'attestation de la proposition. Cependant, la transparence des transactions Filecoin on-chain et l'absence de confidentialité native rendent ce système inadapté au contexte hostile.
+### 2.4 Tor et I2P
 
-### 2.3 BitTorrent DHT (Loewenstern & Norberg, 2008)
+Tor (The Onion Router) [10] anonymise les communications en routant chaque message à travers trois relais avec chiffrement en oignon, de sorte qu'aucun relais ne connaît à la fois la source et la destination. Les services cachés (.onion) permettent d'opérer des serveurs sans révéler leur adresse IP. C'est la solution de référence pour protéger les métadonnées de communication contre des observateurs passifs non globaux.
 
-**Principe** : Le protocole BitTorrent DHT (BEP 5) implémente une DHT Kademlia pour la découverte de pairs partageant des torrents. Chaque nœud maintient une table de routage de pairs proches dans l'espace XOR de Kademlia, permettant de localiser des pairs ayant annoncé un torrent spécifique.
+I2P propose une approche similaire avec un routage en ail (garlic routing) qui agrège plusieurs messages pour réduire la corrélation temporelle, et une architecture plus décentralisée que Tor (pas de directory authorities).
 
-**Forces** :
-- Système très mature, déployé à des centaines de millions de nœuds
-- Résilience exceptionnelle démontrée à grande échelle
-- Protocole simple et bien documenté
-
-**Faiblesses** :
-- Aucune authentification des nœuds : toute clé publique peut être annoncée par n'importe qui
-- Aucune confidentialité : les requêtes DHT révèlent quels contenus sont recherchés
-- Aucun mécanisme de confiance ou de réputation
-- Résistance Sybil nulle
-
-**Compatibilité GARDEN** : Inadapté. BitTorrent DHT constitue une référence historique utile pour comprendre les propriétés de scalabilité et de résilience des DHT Kademlia, mais ses propriétés de sécurité sont incompatibles avec tout contexte hostile.
-
-### 2.4 Tor (Dingledine, Mathewson & Syverson, 2004)
-
-**Principe** : Tor (The Onion Router) est un réseau d'anonymisation par routage en oignon : chaque message est chiffré en plusieurs couches et routé à travers trois nœuds relais (entry guard, middle relay, exit node), de sorte qu'aucun relais unique ne connaît à la fois la source et la destination d'un message. Les services cachés (hidden services, .onion) permettent d'opérer des serveurs sans révéler leur adresse IP.
-
-**Forces** :
-- Confidentialité de transport forte, résistance démontrée contre les observateurs passifs non globaux
-- Résistance à la surveillance ciblée sur les liaisons intermédiaires
-- Écosystème bien documenté, client libre largement déployé
-
-**Faiblesses** :
-- Latences élevées (100–500ms en moyenne) introduites par le routage multi-sauts
-- Vulnérable aux attaques par analyse de trafic global (corrélation temporelle) [Murdoch & Danezis, 2005]
-- Pas de découverte décentralisée de pairs : les directory authorities constituent un point centralisé
-- Pas de transactions monétaires ni de smart contracts
-- Connectivité TCP continue requise : incompatible avec les contraintes DTN
-
-**Compatibilité GARDEN** : Pertinent comme couche de transport pour masquer les métadonnées de communication entre nœuds, en particulier sur les liens exposés à des observateurs passifs. Cependant, Tor ne constitue pas une infrastructure complète pour un système de découverte et de marché de ressources.
-
-### 2.5 I2P (Invisible Internet Project)
-
-**Principe** : I2P est un réseau mixnet utilisant le routage en ail (garlic routing), une variante du routage en oignon où plusieurs messages sont agrégés dans une même "gousse d'ail" pour réduire la corrélation temporelle. I2P est plus décentralisé que Tor (pas de directory authorities) et optimisé pour la communication bidirectionnelle (trafic interne au réseau).
-
-**Forces** :
-- Plus décentralisé que Tor (distributed network database)
-- Meilleure résistance à l'analyse de trafic pour le trafic bidirectionnel
-- Réseau auto-suffisant sans dépendance aux directory authorities
-
-**Faiblesses** :
-- Écosystème et communauté plus petits que Tor
-- Performances de latence comparables à Tor
-- Documentation moins développée
-- Pas adapté aux contraintes DTN
-
-**Compatibilité GARDEN** : Alternative crédible à Tor pour la couche de transport anonymisant, avec l'avantage d'une moindre dépendance à des points centralisés. Comme Tor, ne constitue pas une infrastructure complète.
+Les deux réseaux partagent les mêmes limitations pour GARDEN : latences élevées (100–500ms), connectivité TCP continue requise (incompatible DTN), et absence de toute couche de transactions monétaires ou de découverte décentralisée de pairs. Pertinents comme couche de transport anonymisant sur les liens exposés, pas comme infrastructure complète.
 
 ---
 
 ## 3. Systèmes de Computation et Marketplace Décentralisée
 
-### 3.1 Golem (Golem Network, 2016)
+### 3.1 Golem
 
-**Principe** : Golem est une marketplace de compute décentralisée basée sur Ethereum. Les fournisseurs de ressources (requestors) soumettent des tâches de calcul définies dans un format standardisé ; les prestataires (providers) les exécutent et reçoivent un paiement en tokens GLM. La vérification du bon accomplissement repose sur des challenges cryptographiques sur les résultats.
-
-**Forces** :
-- Marché libre de ressources de calcul
-- Preuve de travail challengeable pour vérification des résultats
-- Décentralisé, pas d'opérateur central
-
-**Faiblesses** :
-- Transactions Ethereum entièrement publiques : qui paie qui, pour quel type de tâche, avec quel montant
-- Latences du réseau Ethereum (finalité probabiliste) incompatibles avec les workloads temps-réel
-- Pas de support DTN
-- Pas de gestion de confiance relative ni de consortiums
-- Pas de confidentialité des tâches exécutées
-
-**Compatibilité GARDEN** : Insuffisant pour un contexte hostile. Le modèle de marketplace de compute est conceptuellement pertinent, mais l'absence de confidentialité et la dépendance à Ethereum public rendent ce système inadapté.
+Golem [16] est une marketplace de compute décentralisée sur Ethereum : les demandeurs soumettent des tâches, les fournisseurs les exécutent et reçoivent des tokens GLM. Le modèle est conceptuellement proche de ce que GARDEN requiert. Le problème est que toutes les transactions sont publiques sur Ethereum, qui paie qui, combien, pour quel type de tâche, ce qui est incompatible avec la souveraineté des données dans un contexte hostile. Pas de support DTN, pas de gestion de confiance relative.
 
 ### 3.2 Akash Network
 
-**Principe** : Akash Network est un marché de déploiement Kubernetes décentralisé basé sur le SDK Cosmos. Les fournisseurs de compute publient leurs offres de ressources Kubernetes ; les utilisateurs soumettent des manifestes de déploiement standardisés (SDL : Stack Definition Language) ; un mécanisme d'enchère inverse attribue les déploiements aux fournisseurs les moins coûteux.
+Akash est sans doute le système de compute décentralisé le plus architecturalement proche de GARDEN. C'est un marché de déploiement Kubernetes basé sur le SDK Cosmos, avec enchères inverses et finalité Tendermint (~6 secondes). L'interopérabilité Cosmos via IBC est un point de compatibilité potentiel réel.
 
-**Forces** :
-- Architecturalement compatible avec Kubernetes (outil standard d'orchestration de conteneurs)
-- Finalité rapide via Tendermint BFT (~6 secondes)
-- Marché de déploiement décentralisé avec enchères transparentes
-- Écosystème Cosmos avec interopérabilité IBC
+Akash reste cependant insuffisant : les déploiements sont publics sur la chaîne, le modèle de confiance est binaire (certifié / non certifié), et il n'existe pas de gestion de consortiums à niveaux de confiance différenciés. C'est un exemple utile de ce que le SDK Cosmos permet de construire, mais pas une solution directement adaptable.
 
-**Faiblesses** :
-- Transactions publiques sur la chaîne Akash : les déploiements sont entièrement visibles
-- Modèle de confiance binaire (fournisseur certifié / non certifié)
-- Pas de confidentialité native des workloads déployés
-- Pas de support DTN
-- Gouvernance de confiance limitée : pas de gestion de consortiums à niveaux de confiance
+### 3.3 iExec
 
-**Compatibilité GARDEN** : Architecturalement proche de ce que GARDEN requiert (Kubernetes décentralisé), mais manque les couches de confidentialité et de gestion de confiance relative indispensables. L'interopérabilité Cosmos constitue un point de compatibilité potentiel.
+iExec intègre des Trusted Execution Environments (TEE) Intel SGX [7] dans une marketplace de compute sur Ethereum : le fournisseur de compute ne peut pas accéder aux données qu'il traite, ce qui est une propriété utile pour l'attestation de consommation de ressources. La dépendance à Intel SGX et la transparence des transactions de marketplace sur Ethereum L1 sont les deux limitations principales pour GARDEN.
 
-### 3.3 iExec (2017)
+### 3.4 Ocean Protocol
 
-**Principe** : iExec est une marketplace de compute décentralisée intégrant des Trusted Execution Environments (TEE) Intel SGX pour l'exécution confidentielle des tâches. Les smart contracts Ethereum gèrent le cycle de vie des tâches et les paiements en tokens RLC. Le TEE garantit que ni le fournisseur de compute ni aucun observateur ne peut accéder au contenu des données traitées.
-
-**Forces** :
-- Exécution confidentielle native via Intel SGX : le fournisseur de compute ne voit pas les données traitées
-- Marketplace décentralisée avec attestations TEE
-- Smart contracts Ethereum pour l'automatisation du paiement
-
-**Faiblesses** :
-- Dépendance critique à Intel SGX : vulnérabilités de canal latéral documentées (Spectre-NG, SGAxe, LVI) [Costan & Devadas, 2016]
-- Transactions de marketplace publiques sur Ethereum L1
-- Pas de support DTN
-- Gouvernance centralisée du réseau TEE
-
-**Compatibilité GARDEN** : Le modèle TEE pour l'exécution confidentielle est pertinent pour le contexte GARDEN, particulièrement pour l'attestation de consommation de ressources (verrou oracle). Cependant, la dépendance à Intel SGX constitue une dépendance matérielle problématique pour des nœuds embarqués spatiaux dont la chaîne d'approvisionnement peut être compromise.
-
-### 3.4 Ocean Protocol (2019)
-
-**Principe** : Ocean Protocol est un marché décentralisé de données basé sur Ethereum. Le mécanisme "Compute-to-Data" permet à un fournisseur de données de proposer l'accès à ses données pour du calcul sans jamais les transférer : le calcul s'exécute au plus près des données, et seul le résultat est retourné au demandeur.
-
-**Forces** :
-- Modèle Compute-to-Data respectant la souveraineté du fournisseur de données
-- Tokenisation des actifs de données (datatokens ERC-20)
-- Décentralisé, écosystème actif
-
-**Faiblesses** :
-- Transactions de marketplace publiques sur Ethereum
-- Confiance basée sur des smart contracts audités, pas sur des preuves cryptographiques d'exécution
-- Pas de support DTN
-- Pas de gestion de consortiums à confiance différenciée
-
-**Compatibilité GARDEN** : Le modèle Compute-to-Data constitue une approche intéressante pour préserver la souveraineté des données dans un marché décentralisé. Cependant, la transparence Ethereum et l'absence de gestion de la confiance relative limitent son applicabilité directe.
+Le mécanisme "Compute-to-Data" d'Ocean Protocol est intéressant : un fournisseur de données peut mettre ses données à disposition pour du calcul sans jamais les transférer, le calcul s'exécute localement, seul le résultat part. C'est une approche qui respecte la souveraineté du fournisseur. La transparence Ethereum et l'absence de gestion de confiance relative limitent son applicabilité directe, mais le modèle Compute-to-Data est une inspiration pertinente pour la couche de données de la proposition.
 
 ---
 
 ## 4. Systèmes Blockchain
 
-### 4.1 Bitcoin (Nakamoto, 2008)
+### 4.1 Bitcoin
 
-**Principe** : Bitcoin est le premier système de règlement monétaire pair-à-pair sans tiers de confiance. La sécurité repose sur une preuve de travail (Proof of Work) permettant d'atteindre un consensus sur l'ordre des transactions sans autorité centrale. La finalité est probabiliste : une transaction est considérée irréversible après ~6 confirmations (~1 heure).
+Bitcoin [28] démontre qu'un consensus sur un ledger partagé est possible sans autorité centrale. Sa sécurité éprouvée sur 15+ ans sans compromission protocolaire est remarquable. Mais l'absence de smart contracts expressifs, la finalité à une heure, et la consommation énergétique du Proof of Work le rendent inutilisable pour le règlement d'un marché de ressources embarqué. Sa valeur pour GARDEN est essentiellement théorique, c'est la preuve que le problème est soluble.
 
-**Forces** :
-- Sécurité éprouvée sur 15+ ans d'opération continue sans compromission protocolaire
-- Décentralisation maximale (aucun opérateur central)
-- Résistance à la censure démontrée
+### 4.2 Ethereum
 
-**Faiblesses** :
-- Pas de smart contracts expressifs (Script très limité)
-- Latence finale (~1 heure) incompatible avec les contraintes opérationnelles
-- Transactions pseudonymes traçables par analyse de graphe [Meiklejohn et al., 2013]
-- Proof of Work : consommation énergétique prohibitive pour contexte embarqué
-- Pas de gestion de consortiums
+Ethereum a apporté les smart contracts à vocation généraliste. La machine virtuelle EVM exécute des programmes Turing-complets, et l'écosystème d'outils, d'audits, et de développeurs est le plus large qui existe. Depuis la migration vers Proof of Stake (The Merge, 2022), la consommation énergétique est devenue raisonnable.
 
-**Compatibilité GARDEN** : Inadapté pour le règlement programmatique et la confidentialité. Valeur de référence théorique uniquement.
+Le problème fondamental reste la transparence totale : toutes les transactions et tous les états de smart contracts sont publics, ce qui rend Ethereum L1 incompatible avec un contexte opérationnel hostile. Les L2 ZK confidentiels (Aztec notamment) représentent une direction prometteuse, mais leur maturité en 2026 reste insuffisante pour un déploiement opérationnel. À noter également le phénomène MEV (Miner Extractable Value) [8] : les validateurs peuvent réordonner les transactions pour extraire de la valeur au détriment des utilisateurs, un risque structurel dans tout marché décentralisé basé sur Ethereum.
 
-### 4.2 Ethereum (Buterin, 2014 ; Wood, 2014)
+### 4.3 Hyperledger Fabric
 
-**Principe** : Ethereum est la première plateforme de smart contracts à vocation généraliste. La machine virtuelle EVM (Ethereum Virtual Machine) exécute des programmes Turing-complets encodés dans des transactions on-chain. La migration vers Proof of Stake (The Merge, 2022) a réduit la consommation énergétique de ~99.95%.
+Hyperledger Fabric [1] est la blockchain de consortium la plus mature disponible. Son architecture distingue les orderers (ordre des transactions), les peers (exécution des chaincode), et les MSP (gestion des identités membres). Les canaux privés permettent à des sous-groupes de membres d'effectuer des transactions confidentielles vis-à-vis du reste du réseau. La finalité est déterministe, pas de forks possibles avec Raft ou PBFT.
 
-**Forces** :
-- EVM : plateforme de smart contracts la plus mature, écosystème DeFi massif
-- Large écosystème de développeurs et d'outils
-- L2 émergents (ZK-rollups, Optimistic rollups) améliorant scalabilité et potentiellement confidentialité
+C'est le candidat le plus adapté parmi les systèmes existants pour un consortium fermé intra-organisation. Sa faiblesse pour GARDEN est double : d'une part la gouvernance repose nécessairement sur la confiance aux opérateurs MSP (pas de trustless), d'autre part la connectivité TCP continue entre peers et orderers est requise, incompatible avec les contraintes DTN.
 
-**Faiblesses** :
-- Transparence totale : toutes les transactions et les états des smart contracts sont publics
-- Phénomène MEV (Miner/Maximal Extractable Value) créant des distorsions de marché [Daian et al., 2020]
-- Finalité probabiliste sur L1 (~12s pour la finalité slot, ~15 minutes pour finalité économique forte)
-- Pas de gestion native des consortiums
-- L2 ZK confidentiels encore en développement actif
+### 4.4 Cosmos / IBC
 
-**Compatibilité GARDEN** : Inadapté en L1 seul. Les L2 ZK confidentiels (Aztec) constituent un axe de développement prometteur mais dont la maturité est insuffisante pour un déploiement opérationnel en 2026. Pertinent comme substrate de référence pour l'écosystème EVM.
+Cosmos [21] part d'une idée fondamentalement différente de tous les systèmes précédents : plutôt que de partager une infrastructure commune, chaque application ou consortium peut opérer sa propre blockchain dédiée, appelée "zone", avec son propre consensus, ses propres règles, et son propre validator set. Les zones communiquent via IBC (Inter-Blockchain Communication), un protocole standardisé qui garantit la livraison exactement une fois avec des propriétés vérifiables par light client.
 
-### 4.3 Hyperledger Fabric (Androulaki et al., 2018)
+**Créer sa propre zone : ce que ça implique concrètement**
 
-**Principe** : Hyperledger Fabric est une blockchain permissionnée conçue pour les consortiums d'entreprises. Son architecture distingue les orderers (responsables de l'ordre des transactions), les peers (exécutant les chaincode et maintenant le ledger), et les MSP (Membership Service Providers, responsables de l'identité des membres). Les canaux privés permettent à des sous-groupes de membres d'effectuer des transactions confidentielles vis-à-vis du reste du réseau.
+Le Cosmos SDK est un framework modulaire en Go qui fournit les composants fondamentaux, consensus Tendermint BFT, mempool, API REST/gRPC, modules bank/staking/governance, sous forme de briques réutilisables et bien testées. Un consortium n'a à écrire que la logique applicative qui lui est propre. L'outil `ignite CLI` (anciennement Starport) génère le squelette d'une zone compilable et fonctionnelle en quelques commandes. Des zones de production comme Osmosis, Akash, ou Injective ont été construites sur cette base; le délai réaliste de mise en production d'une zone dédiée est de quelques semaines à quelques mois, pas d'années.
 
-**Forces** :
-- Canaux privés : confidentialité native pour les sous-consortiums
-- Finalité déterministe : pas de forks possibles avec Raft ou PBFT
-- Modular consensus : le mécanisme de consensus est paramétrable selon les besoins
-- Chaincode (smart contracts) en langages standards (Go, Java, Node.js)
-- Gouvernance fine via les MSP
+Ce qui rend cette approche particulièrement adaptée à GARDEN, c'est la combinaison de trois propriétés :
 
-**Faiblesses** :
-- Permissioned : requiert de faire confiance aux opérateurs des MSP (pas de trustless)
-- Gouvernance centralisée par essence : il faut faire confiance à la structure d'administration
-- Pas de connectivité intermittente supportée nativement : TCP continu requis entre peers et orderers
-- Complexité d'administration élevée
+La **souveraineté du validator set** est totale. Les validateurs de la zone sont entièrement contrôlés par le consortium, qui valide, qui ne valide pas, selon quelles règles. La sécurité économique repose sur le token natif de la zone : les validateurs stakent des tokens qui peuvent être slashés en cas de comportement malveillant. Pour une coalition naissante sans validator set robuste, l'Interchain Security (ICS, activée sur le Cosmos Hub en 2023) permet de déléguer cette sécurité au validator set du Hub, l'un des plus larges de l'écosystème.
 
-**Compatibilité GARDEN** : Très adapté pour les consortiums fermés (intra-consortium dans la proposition). La finalité déterministe et les canaux privés en font le candidat le plus mature pour le règlement intra-consortium. La dépendance à une connectivité TCP continue constitue le principal gap avec les contraintes DTN.
+La **gouvernance onchain native** couvre toutes les décisions du consortium : admissions et exclusions de validateurs, mises à jour de protocole, modifications des paramètres de la chaîne. Ces décisions ne passent pas par un processus hors-bande, elles sont des transactions blockchain ordinaires, soumises au même consensus BFT que les transactions monétaires. Cette convergence évite la fragmentation entre mécanismes de gouvernance et mécanismes de règlement.
 
-### 4.4 Cosmos / IBC (Kwon & Buchman, 2016)
+L'**interopérabilité IBC** permet à une zone de consortium privée de communiquer avec Secret Network pour les transactions confidentielles inter-consortium, ou avec d'autres zones pour les échanges entre coalitions. Un canal IBC entre une zone de consortium et Secret Network permet de déléguer l'exécution confidentielle de contrats de règlement tout en conservant le ledger intra-consortium souverain.
 
-**Principe** : Cosmos est un écosystème de blockchains souveraines et interopérables. Chaque "zone" est une blockchain indépendante avec son propre consensus (généralement Tendermint BFT), sa propre gouvernance et ses propres smart contracts (CosmWasm). Les zones communiquent via le protocole IBC (Inter-Blockchain Communication), permettant des transferts de tokens et de messages entre blockchains hétérogènes.
+CosmWasm, le framework de smart contracts standard de l'écosystème, présente deux avantages structurels sur l'EVM : le modèle d'exécution "actor" élimine les réentrances [24], la principale classe de bugs catastrophiques, et le langage Rust garantit la sécurité mémoire à la compilation.
 
-**Forces** :
-- Zones souveraines : chaque consortium peut opérer sa propre blockchain avec sa propre gouvernance
-- Finalité rapide : Tendermint BFT offre une finalité déterministe en ~6 secondes
-- IBC : interopérabilité standardisée entre zones
-- CosmWasm : smart contracts en Rust avec sécurité mémoire accrue
-- Écosystème large et actif
-
-**Faiblesses** :
-- Pas de confidentialité native : les transactions IBC sont visibles dans les logs des deux zones impliquées
-- Modèle de confiance limité entre zones : pas de mécanisme standardisé pour la confiance relative
-- Complexité d'administration d'une zone Cosmos
-
-**Compatibilité GARDEN** : Excellente base pour une architecture multi-consortium. Chaque consortium peut opérer sa propre zone avec sa gouvernance, et les échanges inter-consortium transitent via IBC. L'absence de confidentialité native est compensable par des solutions applicatives (chiffrement des données avant soumission on-chain) ou par l'utilisation de zones confidentielles (Secret Network, zone Cosmos).
+Les limitations à ne pas occulter : une zone Cosmos standard n'offre pas de confidentialité native (les transactions sont visibles sur l'explorateur), IBC n'est pas DTN-natif (les relayers supposent une connectivité suffisante), et opérer un validator set est une charge opérationnelle réelle.
 
 ### 4.5 Secret Network
 
-**Principe** : Secret Network est une blockchain basée sur Cosmos utilisant des enclaves TEE Intel SGX pour l'exécution confidentielle des smart contracts. Les inputs des transactions, les états des smart contracts, et les outputs sont chiffrés pour les validateurs eux-mêmes : seule la logique du contrat est publique. Les développeurs écrivent des "secret contracts" en CosmWasm avec des annotations de confidentialité.
+Secret Network est une zone Cosmos qui ajoute une couche de confidentialité native à l'exécution des smart contracts via des enclaves Intel SGX [7]. Les inputs des transactions, les états des contrats, et les outputs sont chiffrés non seulement en transit mais aussi vis-à-vis des validateurs eux-mêmes, seule la logique du contrat est publique. Ce qui distingue cette approche d'un simple chiffrement applicatif, c'est que la confidentialité est garantie par l'architecture d'exécution, non par la discipline des développeurs. Un validateur malveillant qui contrôlerait l'infrastructure ne peut pas accéder aux états des contrats confidentiels.
 
-**Forces** :
-- Smart contracts confidentiels natifs : aucun validateur ne peut accéder aux données en clair
-- Compatibilité Cosmos : interopérabilité via IBC avec l'écosystème Cosmos
-- Cas d'usage variés : DeFi privé, DAO confidentielles, bridges confidentiels
-- Finalité Tendermint (~6 secondes)
+Une propriété particulièrement utile pour les marchés de ressources : cette architecture supprime structurellement le MEV basé sur l'information. Un validateur qui ne peut pas lire le contenu des transactions ne peut pas les réordonner à son avantage.
 
-**Faiblesses** :
-- Dépendance critique à Intel SGX : vulnérabilités de canal latéral potentielles [Costan & Devadas, 2016]
-- Pas de garantie de confidentialité si SGX est compromis
-- Complexité de développement supérieure aux smart contracts standard
-- Écosystème plus petit que Ethereum ou Cosmos
+La limitation principale est réelle et doit être assumée : la dépendance à Intel SGX. Des vulnérabilités de canal latéral (Spectre-NG, SGAxe, LVI) ont été documentées sur cette architecture, et les nœuds embarqués spatiaux ne sont pas nécessairement équipés de processeurs Intel certifiés. C'est un compromis pragmatique, accepter une dépendance matérielle en échange d'une confidentialité des smart contracts mature et disponible aujourd'hui. L'alternative à moyen terme est Penumbra [30], une zone Cosmos dont la confidentialité repose sur des zk-SNARKs sans dépendance matérielle, actuellement en développement actif.
 
-**Compatibilité GARDEN** : Bon candidat pour le règlement inter-consortium confidentiel dans la proposition. La dépendance à Intel SGX constitue une limitation pour les nœuds embarqués spatiaux dont la chaîne d'approvisionnement matérielle peut être compromise ou dont la disponibilité de matériel certifié SGX est incertaine.
+### 4.6 Zcash
 
-### 4.6 Zcash (Ben-Sasson et al., 2014 ; Hopwood et al., 2016)
+Zcash [19] utilise les zk-SNARKs pour masquer cryptographiquement les montants et les adresses dans les transactions "shielded". L'avantage clé par rapport aux solutions TEE : la confidentialité repose uniquement sur des primitives cryptographiques, sans dépendance matérielle, plus robuste à long terme contre les attaques physiques sur les nœuds.
 
-**Principe** : Zcash est une blockchain de paiements confidentiels utilisant les zk-SNARKs (Zero-Knowledge Succinct Non-interactive ARguments of Knowledge) pour masquer cryptographiquement les montants transférés et les adresses des parties dans les transactions "shielded". Contrairement aux solutions TEE, la confidentialité repose uniquement sur des primitives cryptographiques, sans dépendance matérielle.
+La limitation est l'absence de smart contracts complexes. Le langage Script de Zcash est très limité, ce qui empêche d'automatiser le règlement conditionnel d'un marché de ressources. Par ailleurs, en pratique la majorité des transactions Zcash ne sont pas shielded, la protection par effet d'ensemble est réduite. Pertinent comme inspiration pour la couche de paiement pure, pas comme infrastructure complète.
 
-**Forces** :
-- Confidentialité cryptographique pure, sans dépendance matérielle
-- zk-SNARKs vérifiables par n'importe quel nœud en O(1) de calcul
-- Technologie ZK mature, référence académique et industrielle
-- Pas de PoW sur la nouvelle architecture (Sapling, Orchard)
+### 4.7 Oasis Network
 
-**Faiblesses** :
-- Pas de smart contracts complexes : le langage Script de Zcash est très limité
-- Les pools shielded sont sous-utilisés (majorité des transactions non-shielded), réduisant l'anonymat par effet d'ensemble
-- Gouvernance fortement centralisée par l'Electric Coin Company
-- Pas adapté pour automatiser le règlement conditionnel d'un marché de ressources
+Oasis [29] propose des "ParaTimes", des environnements d'exécution parallèles avec des niveaux de confidentialité configurables. Le Sapphire ParaTime offre un EVM confidentiel (états des smart contracts chiffrés dans SGX), ce qui permet de bénéficier de la compatibilité avec l'outillage Ethereum tout en ajoutant de la confidentialité. La dépendance SGX est identique à Secret Network. Écosystème plus jeune, mais l'architecture modulaire est intéressante comme référence de conception.
 
-**Compatibilité GARDEN** : Excellent pour les paiements confidentiels simples entre parties connues. L'absence de smart contracts expressifs limite l'automatisation du règlement dans un marché de ressources complexe. Pertinent comme couche de paiement pour des cas d'usage spécifiques ne requérant pas de logique contractuelle.
+### 4.8 Penumbra, Confidentialité ZK Cross-Chain dans l'Écosystème Cosmos
 
-### 4.7 Oasis Network (Oasis Labs, 2020)
+Penumbra est une zone Cosmos dont la proposition est simple à formuler mais techniquement ambitieuse : apporter à l'écosystème Cosmos une couche de confidentialité cryptographique pure, sans aucune dépendance à du matériel TEE, en s'appuyant exclusivement sur des preuves à divulgation nulle (ZK-proofs). C'est, à ce titre, le successeur naturel de Secret Network dans la trajectoire architecturale de GARDEN.
 
-**Principe** : Oasis Network combine TEE et blockchain en proposant des "ParaTimes" — des environnements d'exécution parallèles avec des niveaux de confidentialité configurables. Le Sapphire ParaTime offre un EVM confidentiel (les états des smart contracts sont chiffrés dans SGX), permettant d'exécuter des smart contracts Solidity avec confidentialité des données internes.
+Le modèle de confidentialité de Penumbra est inspiré de Zcash/Sapling mais adapté à un écosystème multi-chaînes. Toutes les transactions sur Penumbra opèrent dans un "shielded pool" : les montants, les adresses des parties, et les assets concernés sont entièrement masqués cryptographiquement. Les validateurs ne voient que des preuves ZK vérifiables, ils confirment que les règles du protocole sont respectées sans accéder aux données sous-jacentes. La confidentialité n'est pas une option ou une couche applicative; c'est le comportement par défaut, ce qui évite le problème d'anonymat par effet d'ensemble qui affecte Zcash (où la majorité des transactions sont non-shielded).
 
-**Forces** :
-- EVM confidentiel : compatibilité avec l'écosystème Ethereum + confidentialité
-- Architecture modulaire (multiple ParaTimes avec différents niveaux de sécurité)
-- Compatibilité Cosmos-adjacent
-- Séparation consensus et exécution : scalabilité accrue
+**La dimension cross-chain est ce qui rend Penumbra directement pertinent pour GARDEN.** Via IBC, des assets provenant de n'importe quelle zone Cosmos peuvent être déposés dans le shielded pool de Penumbra, y être transactés de manière confidentielle, puis retirés vers leur zone d'origine. Concrètement, une zone de consortium A peut envoyer des tokens de règlement via IBC vers Penumbra, exécuter un swap ou un transfert confidentiel avec la zone B, et retirer le résultat, sans que le contenu de l'opération ne soit jamais visible sur l'une ou l'autre des chaînes sources. Le transit par Penumbra agit comme un shielded relay entre zones.
 
-**Faiblesses** :
-- Dépendance à Intel SGX pour les ParaTimes confidentiels
-- Écosystème plus jeune que Secret Network ou Ethereum
-- Complexité d'architecture (multiple ParaTimes à comprendre et gérer)
+Le DEX intégré de Penumbra est aussi un point notable pour le contexte des marchés de ressources : il utilise un mécanisme de batch avec ZK-proofs qui rend structurellement impossible le front-running. Toutes les offres d'une période sont traitées comme un batch sans que l'ordre de soumission soit exploitable, ce qui adresse directement le risque MEV sans dépendre de la confidentialité matérielle.
 
-**Compatibilité GARDEN** : Bon compromis entre smart contracts expressifs (EVM) et confidentialité (TEE). La dépendance SGX est la même limitation que pour Secret Network. La compatibilité EVM facilite le portage de smart contracts existants.
+Là où Penumbra diffère de Secret Network de manière structurelle, c'est dans l'expressivité contractuelle. Secret Network permet des smart contracts arbitraires (CosmWasm) avec confidentialité, logique métier complexe, états persistants, conditions multi-parties. Penumbra est avant tout un protocole de paiement et de swap confidentiels; la logique contractuelle y est bien plus limitée. Pour des cas d'usage de règlement simple (transfert de tokens entre consortiums, swap d'actifs), Penumbra est suffisant et préférable. Pour des contrats de règlement conditionnel complexes (oracles, multi-signatures avec conditions temporelles, escrow multi-parties), Secret Network reste plus adapté aujourd'hui.
+
+L'état de maturité est la limitation principale. Penumbra est en développement actif, testnet depuis 2023, mainnet progressivement. L'écosystème d'outils, la documentation, et le retour d'expérience opérationnel sont encore limités comparés à Secret Network qui est en production depuis 2020. Pour GARDEN, Penumbra est la trajectoire cible à moyen terme, pas la fondation immédiate.
+
+En termes de comparaison directe avec Secret Network : Penumbra élimine la dépendance matérielle SGX (avantage fort pour les nœuds embarqués dont la chaîne d'approvisionnement hardware est incertaine), offre une confidentialité cryptographiquement prouvable plutôt que basée sur une hypothèse de sécurité matérielle, et son modèle cross-chain via IBC est plus nativement intégré. En contrepartie, l'expressivité contractuelle est moindre et la maturité opérationnelle inférieure.
 
 ---
 
@@ -360,113 +186,139 @@ Les critères suivants sont retenus pour l'analyse comparative. Chaque critère
 | Secret Network | ✓ | ✓✓ | ✓ | ✗ | ✓✓ | ✓✓ | N/A (règlement seul) | ✓ | ✓ | △ |
 | Zcash | ✓ | ✓✓ | ✓ | ✗ | △ | ✗ | N/A (règlement seul) | ✗ | ✓✓ | ✗ |
 | Oasis Network | ✓ | ✓✓ | ✓ | ✗ | ✓✓ | ✓✓ | N/A (règlement seul) | △ | ✓ | △ |
+| Penumbra | ✓✓ | ✓✓ (ZK) | ✓ | ✗ | ✓✓ | △ | N/A (règlement seul) | ✓ | △ | △ |
 | **Proposition** | **✓✓** | **✓✓** | **✓** | **✓✓** | **✓✓** | **✓✓** | **✓✓ (3 plans distincts)** | **✓✓** | **△** | **✓✓** |
 
 *Notation : ✓✓ excellent, ✓ bon, △ partiel ou conditionnel, ✗ insuffisant, N/A non applicable*
 
-> **Lecture de la colonne "Séparation découverte/règlement"** : Les systèmes notés N/A n'implémentent qu'une seule des deux fonctions (découverte ou règlement), sans prétendre à l'autre. Les systèmes notés ✗ couplent les deux dans un même protocole ou une même chaîne, créant des compromis défavorables. Seule la proposition formalise explicitement la séparation en trois plans indépendants avec des profils CAP distincts.
+> **Lecture de la colonne "Séparation découverte/règlement"** : Les systèmes notés N/A n'implémentent qu'une seule des deux fonctions, sans prétendre à l'autre. Les systèmes notés ✗ couplent les deux dans un même protocole, créant des compromis défavorables. Seule la proposition formalise explicitement la séparation en trois plans indépendants avec des profils CAP distincts.
 
 ---
 
 ## 6. Positionnement de la Proposition par Rapport à l'Existant
 
-### 6.1 L'Absence d'une Solution Intégrée dans l'État de l'Art
+### 6.1 L'Absence d'une Solution Intégrée
 
-L'analyse comparative révèle une lacune structurelle dans l'état de l'art : **aucun système existant ne combine simultanément l'ensemble des propriétés requises par le contexte GARDEN**. Les systèmes actuels se spécialisent sur un sous-ensemble de propriétés, laissant des gaps critiques selon leur domaine de conception.
+Aucun système existant ne combine simultanément l'ensemble des propriétés requises par le contexte GARDEN. Ce n'est pas une surprise, les systèmes se spécialisent naturellement sur un sous-ensemble de propriétés qui correspondent à leur contexte de conception originel.
 
-Les systèmes de découverte P2P (IPFS, libp2p, BitTorrent DHT) excellent en décentralisation et en scalabilité mais ignorent la confidentialité et la gestion de confiance. Les réseaux d'anonymisation (Tor, I2P) offrent une excellente confidentialité de transport mais ne fournissent ni découverte décentralisée, ni transactions monétaires, ni tolérance DTN. Les blockchains de consortium (Hyperledger Fabric) offrent confidentialité intra-consortium et finalité déterministe mais supposent une connectivité continue et ne s'intègrent pas avec une couche de découverte P2P. Les blockchains confidentielles (Secret Network, Oasis) offrent des smart contracts confidentiels mais présentent des dépendances matérielles problématiques et ne traitent pas la couche de découverte.
+Les systèmes de découverte P2P excellent en décentralisation et en scalabilité mais ignorent la confidentialité et la gestion de confiance. Les réseaux d'anonymisation offrent une excellente confidentialité de transport mais ne fournissent ni découverte décentralisée, ni transactions monétaires, ni tolérance DTN. Les blockchains de consortium offrent confidentialité intra-consortium et finalité déterministe mais supposent une connectivité continue et ne s'intègrent pas avec une couche de découverte P2P. Les blockchains confidentielles offrent des smart contracts confidentiels mais présentent des dépendances matérielles et ne traitent pas la découverte.
 
 ### 6.2 La Proposition comme Synthèse Architecturale
 
-La proposition se distingue de tous les systèmes existants par sa nature de **synthèse architecturale multi-couche**, combinant :
+La proposition se distingue de tous les systèmes existants par sa nature de synthèse architecturale multi-couche :
 
-1. **Couche de découverte** : DHT Kademlia privée (inspiration libp2p) + scoring comportemental multidimensionnel (absent de tous les systèmes existants) + adaptation DTN (absent de tous les systèmes existants) + gossip épidémique SWIM-adjacent [Das et al., 2002].
+1. **Couche de découverte** : DHT Kademlia privée (inspiration libp2p) + scoring comportemental multidimensionnel + protocole SWIM complet avec membership épidémique. Aucun de ces éléments pris séparément n'est nouveau, leur combinaison dans un contexte hostile et embarqué constitue la contribution originale.
 
-2. **Couche de données** : enregistrements signés + chiffrement de contenu bout-en-bout + attestations ZK (inspiration Filecoin PoSt, mais avec confidentialité cryptographique) + Compute-to-Data (inspiration Ocean Protocol, mais avec preuves ZK).
+2. **Couche DTN** : cache de messages à deux niveaux (critique / modéré) avec persistance locale chiffrée, mécanisme de réveil intégré aux heartbeats existants sans goroutine additionnelle, et hiérarchie Nano/Maître pour les nœuds à très faible disponibilité avec réconciliation déterministe des conflits à la reconnexion.
 
-3. **Couche de règlement** : architecture hybride intra/inter-consortium (Hyperledger Fabric + Secret Network / Cosmos + Secret Network) + gestion de consortiums à niveaux de confiance différenciés (absent de tous les systèmes existants comme propriété native).
+3. **Couche de données** : enregistrements signés + chiffrement bout-en-bout + attestations cryptographiques de consommation + Compute-to-Data avec preuves ZK.
 
-### 6.3 La Tolérance DTN : Le Gap le Plus Universel
+4. **Couche de règlement** : architecture hybride intra/inter-consortium avec gestion de consortiums à niveaux de confiance différenciés, propriété absente de tous les systèmes existants comme fonctionnalité native. Piste privilégiée : zones Cosmos souveraines + règlement inter-consortium confidentiel via Secret Network (TEE) ou, à terme, Penumbra (ZK pur).
 
-La tolérance aux réseaux DTN est la propriété la plus universellement absente des systèmes existants. Tous les systèmes analysés supposent implicitement ou explicitement une connectivité TCP continue :
-- Les DHT Kademlia supposent une disponibilité suffisante des pairs pour maintenir les tables de routage
-- Les blockchains supposent une connectivité entre validateurs pour atteindre le quorum de consensus
-- Les systèmes de marketplace supposent la disponibilité en temps quasi-réel des parties contractantes
+### 6.3 La Tolérance DTN : Un Gap Structurellement Adressé dans les Couches P2P
 
-La proposition adresse ce gap en adaptant chaque couche aux contraintes DTN : TTL adaptatifs, stockage-et-retransmission, signature différée, heartbeats asynchrones accumulés. Cette adaptation systématique est, à notre connaissance, absente de tout système de marché de ressources décentralisé existant.
+La tolérance DTN est la propriété la plus universellement absente des systèmes existants. Tous supposent une connectivité TCP continue, les DHT pour maintenir leurs tables de routage, les blockchains pour atteindre le quorum de consensus, les marketplaces pour la disponibilité des parties contractantes.
+
+La proposition adresse ce gap de manière systématique dans les couches de découverte et de données. L'adaptation, TTL adaptatifs, cache de messages persistant, réveil piggybacked sur les heartbeats, délégation Nano/Maître pour les satellites, est cohérente et absente de tout système de marché de ressources décentralisé existant. Les détails de ces mécanismes sont documentés dans la proposition architecturale.
+
+Le gap résiduel se situe dans la couche de règlement monétaire. Aucun système blockchain analysé ne gère nativement l'intermittence des validateurs sur de longues périodes. Cette limitation est à adresser au niveau du dimensionnement du validator set et d'une conception explicite des périodes d'isolation dans la configuration du consensus.
+
+### 6.4 Piste Privilégiée pour le Règlement Monétaire : Cosmos avec Confidentialité Déléguée
+
+L'analyse comparative fait émerger une piste préférentielle pour la couche de règlement monétaire, la couche pour laquelle les exigences de finalité déterministe, de confidentialité et de gouvernance souveraine sont les plus contraignantes.
+
+L'écosystème Cosmos est le seul parmi tous les systèmes analysés à satisfaire simultanément trois conditions structurelles : souveraineté (chaque consortium opère sa propre blockchain sans tutelle externe), interopérabilité standardisée (IBC avec guaranties formelles), et accessibilité pratique (bootstrap en semaines avec le SDK + ignite CLI). La confidentialité, absente d'une zone standard, est apportée par délégation via IBC à Secret Network pour les contrats de règlement inter-consortium.
+
+L'architecture cible pour GARDEN se décline ainsi :
+
+```
+Zone Cosmos Consortium A ─── IBC ───┐
+Zone Cosmos Consortium B ─── IBC ───┤──► Secret Network
+Zone Cosmos Consortium C ─── IBC ───┘     (règlement inter-consortium confidentiel)
+```
+
+Chaque zone de consortium gère son propre ledger intra-consortium. Les transactions inter-consortium, les plus sensibles, transitent par Secret Network, où un smart contract confidentiel exécute le règlement sans exposer montants ni parties.
+
+La dépendance SGX de Secret Network est un compromis pragmatique à assumer lucidement : c'est aujourd'hui la solution de confidentialité des smart contracts la plus mature pour l'écosystème Cosmos. La conception architecturale doit anticiper une migration vers Penumbra, zone Cosmos dont la confidentialité repose sur des zk-SNARKs sans dépendance matérielle, dont le développement avance activement. Les contrats de règlement doivent être conçus comme une implémentation interchangeable d'une interface, non comme une dépendance irréversible.
+
+Il vaut la peine de le rappeler explicitement : cette piste concerne **exclusivement la couche de règlement monétaire**. Les couches de découverte P2P et de gestion des données opèrent selon des mécanismes distincts documentés dans les propositions architecturales associées, la séparation entre ces couches étant elle-même l'une des contributions originales de la proposition.
 
 ---
 
 ## Références Bibliographiques
 
-**[Androulaki et al., 2018]** Androulaki, E., et al. (2018). Hyperledger Fabric: a distributed operating system for permissioned blockchains. In *Proceedings of the 13th EuroSys Conference*, article 30.
+**[1] [Androulaki et al., 2018]** Androulaki, E., et al. (2018). Hyperledger Fabric: a distributed operating system for permissioned blockchains. In *Proceedings of the 13th EuroSys Conference*, article 30.
 
-**[Ben-Sasson et al., 2014]** Ben-Sasson, E., Chiesa, A., Garman, C., Green, M., Miers, I., Tromer, E., & Virza, M. (2014). Zerocash: Decentralized Anonymous Payments from Bitcoin. In *Proceedings of the 2014 IEEE S&P*, pp. 459–474.
+**[2] [Ben-Sasson et al., 2014]** Ben-Sasson, E., et al. (2014). Zerocash: Decentralized Anonymous Payments from Bitcoin. In *Proceedings of the 2014 IEEE S&P*, pp. 459–474.
 
-**[Benet, 2014]** Benet, J. (2014). IPFS - Content Addressed, Versioned, P2P File System. *arXiv preprint* arXiv:1407.3561.
+**[3] [Benet, 2014]** Benet, J. (2014). IPFS - Content Addressed, Versioned, P2P File System. *arXiv preprint* arXiv:1407.3561.
 
-**[Brewer, 2000]** Brewer, E. A. (2000). Towards robust distributed systems. In *Proceedings of PODC 2000*, pp. 7.
+**[4] [Brewer, 2000]** Brewer, E. A. (2000). Towards robust distributed systems. In *Proceedings of PODC 2000*, pp. 7.
 
-**[Buterin, 2014]** Buterin, V. (2014). *A Next-Generation Smart Contract and Decentralized Application Platform*. Ethereum Whitepaper. https://ethereum.org/whitepaper
+**[5] [Buterin, 2014]** Buterin, V. (2014). *A Next-Generation Smart Contract and Decentralized Application Platform*. Ethereum Whitepaper.
 
-**[Cerf et al., 2007]** Cerf, V., et al. (2007). Delay-Tolerant Networking Architecture. *RFC 4838*, IETF.
+**[6] [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.
+**[7] [Costan & Devadas, 2016]** Costan, V., & Devadas, S. (2016). Intel SGX Explained. *IACR Cryptology ePrint Archive*, Report 2016/086.
 
-**[Daian et al., 2020]** Daian, P., et al. (2020). Flash Boys 2.0. In *Proceedings of the 2020 IEEE S&P*, pp. 910–927.
+**[8] [Daian et al., 2020]** Daian, P., et al. (2020). Flash Boys 2.0. In *Proceedings of the 2020 IEEE S&P*, pp. 910–927.
 
-**[Das et al., 2002]** Das, A., Gupta, I., & Motivala, A. (2002). SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol. In *Proceedings of DSN 2002*, pp. 303–312.
+**[9] [Das et al., 2002]** Das, A., Gupta, I., & Motivala, A. (2002). SWIM: Scalable Weakly-consistent Infection-style Process Group Membership Protocol. In *Proceedings of DSN 2002*, pp. 303–312.
 
-**[Dingledine, Mathewson & Syverson, 2004]** Dingledine, R., Mathewson, N., & Syverson, P. (2004). Tor: The Second-Generation Onion Router. In *Proceedings of the 13th USENIX Security Symposium*, pp. 303–320.
+**[10] [Dingledine, Mathewson & Syverson, 2004]** Dingledine, R., Mathewson, N., & Syverson, P. (2004). Tor: The Second-Generation Onion Router. In *Proceedings of the 13th USENIX Security Symposium*, pp. 303–320.
 
-**[Douceur, 2002]** Douceur, J. R. (2002). The Sybil Attack. In *Proceedings of IPTPS 2002*, LNCS 2429, pp. 251–260.
+**[11] [Douceur, 2002]** Douceur, J. R. (2002). The Sybil Attack. In *Proceedings of IPTPS 2002*, LNCS 2429, pp. 251–260.
 
-**[Fall, 2003]** Fall, K. (2003). A delay-tolerant network architecture for challenged internets. In *Proceedings of SIGCOMM 2003*, pp. 27–34.
+**[12] [Fall, 2003]** Fall, K. (2003). A delay-tolerant network architecture for challenged internets. In *Proceedings of SIGCOMM 2003*, pp. 27–34.
 
-**[Fischer, Lynch & Paterson, 1985]** Fischer, M. J., Lynch, N. A., & Paterson, M. S. (1985). Impossibility of distributed consensus with one faulty process. *JACM*, 32(2), 374–382.
+**[13] [Fischer, Lynch & Paterson, 1985]** Fischer, M. J., Lynch, N. A., & Paterson, M. S. (1985). Impossibility of distributed consensus with one faulty process. *JACM*, 32(2), 374–382.
 
-**[Gilbert & Lynch, 2002]** Gilbert, S., & Lynch, N. (2002). Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. *ACM SIGACT News*, 33(2), 51–59.
+**[14] [Gilbert & Lynch, 2002]** Gilbert, S., & Lynch, N. (2002). Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services. *ACM SIGACT News*, 33(2), 51–59.
 
-**[Goldwasser, Micali & Rackoff, 1989]** Goldwasser, S., Micali, S., & Rackoff, C. (1989). The knowledge complexity of interactive proof systems. *SIAM Journal on Computing*, 18(1), 186–208.
+**[15] [Goldwasser, Micali & Rackoff, 1989]** Goldwasser, S., Micali, S., & Rackoff, C. (1989). The knowledge complexity of interactive proof systems. *SIAM Journal on Computing*, 18(1), 186–208.
 
-**[Golem Network, 2016]** Golem Network (2016). *Golem: A decentralized computation network*. Whitepaper. https://golem.network/golem_whitepaper.pdf
+**[16] [Golem Network, 2016]** Golem Network (2016). *Golem: A decentralized computation network*. Whitepaper.
 
-**[Groth, 2016]** Groth, J. (2016). On the size of pairing-based non-interactive arguments. In *Proceedings of EUROCRYPT 2016*, LNCS 9666, pp. 305–326.
+**[17] [Groth, 2016]** Groth, J. (2016). On the size of pairing-based non-interactive arguments. In *Proceedings of EUROCRYPT 2016*, LNCS 9666, pp. 305–326.
 
-**[Heilman et al., 2015]** Heilman, E., Kendler, A., Zohar, A., & Goldberg, S. (2015). Eclipse Attacks on Bitcoin's Peer-to-Peer Network. In *Proceedings of the 24th USENIX Security Symposium*, pp. 129–144.
+**[18] [Heilman et al., 2015]** Heilman, E., et al. (2015). Eclipse Attacks on Bitcoin's Peer-to-Peer Network. In *Proceedings of the 24th USENIX Security Symposium*, pp. 129–144.
 
-**[Hopwood et al., 2016]** Hopwood, D., Bowe, S., Hornby, T., & Wilcox, N. (2016). *Zcash Protocol Specification*. Electric Coin Company.
+**[19] [Hopwood et al., 2016]** Hopwood, D., et al. (2016). *Zcash Protocol Specification*. Electric Coin Company.
 
-**[Kwon & Buchman, 2016]** Kwon, J., & Buchman, E. (2016). *Cosmos: A Network of Distributed Ledgers*. Whitepaper.
+**[20] [Kwon, 2014]** Kwon, J. (2014). *Tendermint: Consensus without Mining*. Draft whitepaper.
 
-**[Lamport, Shostak & Pease, 1982]** Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine Generals Problem. *ACM TOPLAS*, 4(3), 382–401.
+**[21] [Kwon & Buchman, 2016]** Kwon, J., & Buchman, E. (2016). *Cosmos: A Network of Distributed Ledgers*. Whitepaper.
 
-**[Loewenstern & Norberg, 2008]** Loewenstern, A., & Norberg, A. (2008). *DHT Protocol (BEP 5)*. BitTorrent Enhancement Proposal.
+**[22] [Lamport, Shostak & Pease, 1982]** Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine Generals Problem. *ACM TOPLAS*, 4(3), 382–401.
 
-**[Luu et al., 2016]** Luu, L., Chu, D.-H., Olickel, H., Saxena, P., & Hobor, A. (2016). Making Smart Contracts Smarter. In *Proceedings of CCS 2016*, pp. 254–269.
+**[23] [Loewenstern & Norberg, 2008]** Loewenstern, A., & Norberg, A. (2008). *DHT Protocol (BEP 5)*. BitTorrent Enhancement Proposal.
 
-**[Maymounkov & Mazières, 2002]** Maymounkov, P., & Mazières, D. (2002). Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. In *Proceedings of IPTPS 2002*, LNCS 2429, pp. 53–65.
+**[24] [Luu et al., 2016]** Luu, L., et al. (2016). Making Smart Contracts Smarter. In *Proceedings of CCS 2016*, pp. 254–269.
 
-**[Meiklejohn et al., 2013]** Meiklejohn, S., et al. (2013). A Fistful of Bitcoins. In *Proceedings of IMC 2013*, pp. 127–140.
+**[25] [Maymounkov & Mazières, 2002]** Maymounkov, P., & Mazières, D. (2002). Kademlia: A Peer-to-Peer Information System Based on the XOR Metric. In *Proceedings of IPTPS 2002*, LNCS 2429, pp. 53–65.
 
-**[Murdoch & Danezis, 2005]** Murdoch, S. J., & Danezis, G. (2005). Low-Cost Traffic Analysis of Tor. In *Proceedings of the 2005 IEEE S&P*, pp. 183–195.
+**[26] [Meiklejohn et al., 2013]** Meiklejohn, S., et al. (2013). A Fistful of Bitcoins. In *Proceedings of IMC 2013*, pp. 127–140.
 
-**[Nakamoto, 2008]** Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf
+**[27] [Murdoch & Danezis, 2005]** Murdoch, S. J., & Danezis, G. (2005). Low-Cost Traffic Analysis of Tor. In *Proceedings of the 2005 IEEE S&P*, pp. 183–195.
 
-**[Oasis Labs, 2020]** Oasis Network (2020). *Oasis Network Primer*. https://oasisprotocol.org/primer
+**[28] [Nakamoto, 2008]** Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf
 
-**[Perrin, 2018]** Perrin, T. (2018). *The Noise Protocol Framework*. https://noiseprotocol.org/noise.pdf
+**[29] [Oasis Labs, 2020]** Oasis Network (2020). *Oasis Network Primer*. https://oasisprotocol.org/primer
 
-**[Protocol Labs, 2017]** Protocol Labs (2017). *Filecoin: A Decentralized Storage Network*. Whitepaper.
+**[30] [Penumbra Labs, 2022]** Penumbra Labs (2022). *Penumbra: A Fully Private Proof-of-Stake Network for the Cosmos Ecosystem*. Technical specification. https://penumbra.zone
 
-**[Stoica et al., 2003]** Stoica, I., et al. (2003). Chord: A scalable peer-to-peer lookup protocol for internet applications. *IEEE/ACM Transactions on Networking*, 11(1), 17–32.
+**[31] [Perrin, 2018]** Perrin, T. (2018). *The Noise Protocol Framework*. https://noiseprotocol.org/noise.pdf
 
-**[Sun et al., 2017]** Sun, S.-F., Au, M. H., Liu, J. K., & Yuen, T. H. (2017). RingCT 2.0. In *Proceedings of ESORICS 2017*, LNCS 10493, pp. 456–474.
+**[32] [Protocol Labs, 2017]** Protocol Labs (2017). *Filecoin: A Decentralized Storage Network*. Whitepaper.
 
-**[Szabo, 1997]** Szabo, N. (1997). Formalizing and securing relationships on public networks. *First Monday*, 2(9).
+**[33] [Stoica et al., 2003]** Stoica, I., et al. (2003). Chord: A scalable peer-to-peer lookup protocol for internet applications. *IEEE/ACM Transactions on Networking*, 11(1), 17–32.
 
-**[W3C, 2022]** W3C (2022). *Decentralized Identifiers (DIDs) v1.0*. https://www.w3.org/TR/did-core/
+**[34] [Sun et al., 2017]** Sun, S.-F., et al. (2017). RingCT 2.0. In *Proceedings of ESORICS 2017*, LNCS 10493, pp. 456–474.
 
-**[Wood, 2014]** Wood, G. (2014). *Ethereum: A Secure Decentralised Generalised Transaction Ledger*. Ethereum Yellow Paper.
+**[35] [Szabo, 1997]** Szabo, N. (1997). Formalizing and securing relationships on public networks. *First Monday*, 2(9).
 
-**[Wood, 2016]** Wood, G. (2016). *Polkadot: Vision for a Heterogeneous Multi-Chain Framework*. Whitepaper.
+**[36] [W3C, 2022]** W3C (2022). *Decentralized Identifiers (DIDs) v1.0*. https://www.w3.org/TR/did-core/
+
+**[37] [Wood, 2014]** Wood, G. (2014). *Ethereum: A Secure Decentralised Generalised Transaction Ledger*. Ethereum Yellow Paper.
+
+**[38] [Wood, 2016]** Wood, G. (2016). *Polkadot: Vision for a Heterogeneous Multi-Chain Framework*. Whitepaper.