oc-discovery/docs/COMPARAISON_SYSTEMES_ET_PROPOSITION.md

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 Domaine d'application : Systèmes embarqués, contexte spatial, réseaux hostiles, marchés de ressources décentralisés Version : 1.1 — Mars 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.

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.

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, 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.

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.

---

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
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
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
Adaptabilité embarquée	Fonctionnalité sous contraintes énergétiques et de bande passante sévères	Nœuds spatiaux à ressources limitées

---

2. Systèmes de Découverte et Stockage P2P

2.1 IPFS / Libp2p (Benet, 2014)

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.

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

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

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 (Protocol Labs, 2017)

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.

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é

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

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.3 BitTorrent DHT (Loewenstern & Norberg, 2008)

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.

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.

---

3. Systèmes de Computation et Marketplace Décentralisée

3.1 Golem (Golem Network, 2016)

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é.

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.

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

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

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.

3.3 iExec (2017)

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.

---

4. Systèmes Blockchain

4.1 Bitcoin (Nakamoto, 2008)

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).

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

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

Compatibilité GARDEN : Inadapté pour le règlement programmatique et la confidentialité. Valeur de référence théorique uniquement.

4.2 Ethereum (Buterin, 2014 ; Wood, 2014)

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%.

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é

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

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.

4.3 Hyperledger Fabric (Androulaki et al., 2018)

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.

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

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

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.

4.4 Cosmos / IBC (Kwon & Buchman, 2016)

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.

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).

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é.

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)

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

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 (Ben-Sasson et al., 2014 ; Hopwood et al., 2016)

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.

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)

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

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.7 Oasis Network (Oasis Labs, 2020)

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.

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

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)

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.

---

5. Tableau de Comparaison Synthétique

Système	Décentralisation	Confidentialité	Sybil-résistance	Tolérance DTN	Finalité	Smart contracts	Séparation découverte/règlement	Consortium	Maturité	Embarqué
IPFS / Libp2p	✓✓	✗	✗	△	N/A	N/A	✗ (découverte seule)	✗	✓✓	△
Filecoin	✓✓	✗	△	✗	△	△	△ (discovery + storage couplés)	✗	✓	✗
BitTorrent DHT	✓✓	✗	✗	△	N/A	N/A	✗ (découverte seule)	✗	✓✓	△
Tor	✓	✓✓	△	✗	N/A	N/A	N/A (transport uniquement)	✗	✓✓	✗
I2P	✓✓	✓✓	△	✗	N/A	N/A	N/A (transport uniquement)	✗	✓	✗
Golem	✓	✗	△	✗	△	△	✗ (couplé Ethereum)	✗	✓	✗
Akash Network	✓	✗	△	✗	✓✓	△	✗ (couplé Cosmos)	△	✓	△
iExec	✓	✓ (TEE)	△	✗	△	△	✗ (couplé Ethereum)	✗	✓	✗
Ocean Protocol	✓	△	△	✗	△	△	✗ (couplé Ethereum)	✗	✓	✗
Bitcoin	✓✓	✗	✓✓	✗	✗	✗	N/A (règlement seul)	✗	✓✓	✗
Ethereum L1	✓✓	✗	✓	✗	△	✓✓	N/A (règlement seul)	✗	✓✓	✗
Ethereum L2 ZK	✓	✓	✓	✗	△	✓	N/A (règlement seul)	✗	△	✗
Hyperledger Fabric	△	✓✓	✓✓	✗	✓✓	✓✓	N/A (règlement seul)	✓✓	✓✓	△
Cosmos SDK + IBC	✓✓	△	✓	✗	✓✓	✓	N/A (règlement seul)	✓✓	✓✓	△
Secret Network	✓	✓✓	✓	✗	✓✓	✓✓	N/A (règlement seul)	✓	✓	△
Zcash	✓	✓✓	✓	✗	△	✗	N/A (règlement seul)	✗	✓✓	✗
Oasis Network	✓	✓✓	✓	✗	✓✓	✓✓	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.

---

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

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.

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.

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 :

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].

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).

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).

6.3 La Tolérance DTN : Le Gap le Plus Universel

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

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.

---

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.

[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.

[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.

[Buterin, 2014] Buterin, V. (2014). A Next-Generation Smart Contract and Decentralized Application Platform. Ethereum Whitepaper. https://ethereum.org/whitepaper

[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.

[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.

[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.

[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.

[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.

[Golem Network, 2016] Golem Network (2016). Golem: A decentralized computation network. Whitepaper. https://golem.network/golem_whitepaper.pdf

[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.

[Hopwood et al., 2016] Hopwood, D., Bowe, S., Hornby, T., & Wilcox, N. (2016). Zcash Protocol Specification. Electric Coin Company.

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

[Lamport, Shostak & Pease, 1982] Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine Generals Problem. ACM TOPLAS, 4(3), 382–401.

[Loewenstern & Norberg, 2008] Loewenstern, A., & Norberg, A. (2008). DHT Protocol (BEP 5). BitTorrent Enhancement Proposal.

[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.

[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.

[Meiklejohn et al., 2013] Meiklejohn, S., et al. (2013). A Fistful of Bitcoins. In Proceedings of IMC 2013, pp. 127–140.

[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.

[Nakamoto, 2008] Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf

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

[Perrin, 2018] Perrin, T. (2018). The Noise Protocol Framework. https://noiseprotocol.org/noise.pdf

[Protocol Labs, 2017] Protocol Labs (2017). Filecoin: A Decentralized Storage Network. Whitepaper.

[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.

[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.

[Szabo, 1997] Szabo, N. (1997). Formalizing and securing relationships on public networks. First Monday, 2(9).

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

[Wood, 2014] Wood, G. (2014). Ethereum: A Secure Decentralised Generalised Transaction Ledger. Ethereum Yellow Paper.

[Wood, 2016] Wood, G. (2016). Polkadot: Vision for a Heterogeneous Multi-Chain Framework. Whitepaper.