464 lines
51 KiB
Markdown
464 lines
51 KiB
Markdown
|
# Proposition d'Architecture Minimale pour un Réseau Décentralisé Souverain dans un Contexte Embarqué et Hostile
|
|||
|
|
|
|||
|
|
**Catégorie** : Architecture des systèmes distribués — Proposition de conception
|
|||
|
|
**Domaine d'application** : Systèmes embarqués, contexte spatial, réseaux DTN, environnements hostiles
|
|||
|
|
**Version** : 1.0 — Mars 2026
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Résumé
|
|||
|
|
|
|||
|
|
Ce document présente une proposition d'architecture minimale pour un réseau distribué décentralisé répondant aux exigences de souveraineté, de confidentialité, et de tolérance aux disruptions réseau dans des environnements hostiles tels que les systèmes spatiaux embarqués ou les réseaux opérant en présence d'adversaires actifs. Le contexte cible — désigné GARDEN (Generic Architecture for Resilient Decentralized Execution Networks) — impose des contraintes qui rendent inadaptée toute solution standard : connectivité intermittente (paradigme DTN [Fall, 2003 ; Cerf et al., 2007]), présence d'acteurs à niveaux de confiance hétérogènes incluant des adversaires d'État, contraintes énergétiques et de bande passante sévères, et exigence de souveraineté absolue des données sur les acteurs externes.
|
|||
|
|
|
|||
|
|
L'architecture proposée repose sur une séparation stricte en trois plans indépendants : le plan de découverte de pairs, le plan de transactions de ressources, et le plan de règlement monétaire. Cette séparation n'est pas un choix stylistique mais une nécessité de sécurité : chaque plan présente des exigences de disponibilité, de cohérence et de confidentialité fondamentalement différentes, et leur fusion dans un protocole unique crée des couplages qui dégradent les garanties de sécurité de chacun.
|
|||
|
|
|
|||
|
|
La proposition couvre en détail les sept couches fonctionnelles de cette architecture : le transport chiffré (Noise Protocol Framework [Perrin, 2018]), la découverte DHT avec scoring comportemental multidimensionnel, la gestion des enregistrements de ressources avec chiffrement bout-en-bout, l'attestation de consommation par preuves à divulgation nulle (ZK-proofs [Groth, 2016]), le règlement monétaire par blockchain confidentielle (analyse comparative de dix solutions), et la gouvernance des consortiums à confiance relative.
|
|||
|
|
|
|||
|
|
Huit verrous conceptuels et technologiques sont identifiés et analysés : identité sans autorité centrale (TOFU), bootstrap trustless, résistance Sybil sans coût cryptoéconomique, cohérence CAP dans un réseau AP, détection de panne sans oracle (FLP), confidentialité des transactions on-chain, transactions intermittentes en contexte DTN, et oracle problem pour les preuves de consommation réelle. Pour chaque verrou, l'état de l'art des solutions disponibles est présenté avec leurs limites résiduelles.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 1. Principes Directeurs Non-Négociables
|
|||
|
|
|
|||
|
|
Les principes suivants constituent les invariants de l'architecture proposée. Tout compromis sur ces principes dégrade structurellement la sécurité du système dans le contexte hostile cible.
|
|||
|
|
|
|||
|
|
### Principe 1 — Souveraineté par Défaut
|
|||
|
|
|
|||
|
|
Aucune donnée ne doit quitter le périmètre de confiance d'un acteur sans son consentement explicite. Ce principe s'applique à toutes les couches : les enregistrements de présence dans la DHT, les transactions de ressources, et le règlement monétaire. La souveraineté s'entend au sens technique (contrôle cryptographique du cycle de vie des données) et opérationnel (possibilité de révocation et d'expiration contrôlée).
|
|||
|
|
|
|||
|
|
### Principe 2 — Confiance Relative et Continue (Non-Binaire)
|
|||
|
|
|
|||
|
|
Le modèle de confiance ne peut être binaire dans un réseau hostile. Chaque pair se voit associer un score de confiance multidimensionnel calculé sur la base de comportements observés (disponibilité historique, précision des challenges, cohérence des données annoncées, diversité réseau). Ce score évolue dans le temps et détermine dynamiquement les interactions autorisées. L'impossibilité de distinguer panne et lenteur (FLP [Fischer, Lynch & Paterson, 1985]) implique que ce score est probabiliste par nature.
|
|||
|
|
|
|||
|
|
### Principe 3 — Disponibilité Prioritaire pour la Découverte, Cohérence Prioritaire pour le Règlement
|
|||
|
|
|
|||
|
|
La couche de découverte adopte délibérément le profil AP du théorème CAP [Brewer, 2000 ; Gilbert & Lynch, 2002] : elle doit rester opérationnelle même en cas de partitionnement, au prix d'une cohérence éventuellement relâchée. La couche de règlement monétaire adopte le profil CP : la cohérence forte est requise pour la prévention du double-spend, au prix d'une indisponibilité temporaire lors des partitions.
|
|||
|
|
|
|||
|
|
### Principe 4 — Opérabilité en Mode Complètement Autonome
|
|||
|
|
|
|||
|
|
Un nœud doit pouvoir opérer — prendre des décisions, gérer ses ressources locales, maintenir un état cohérent — sans aucune connexion réseau pendant des durées pouvant atteindre plusieurs jours. Les protocoles de resynchronisation après reconnexion doivent être déterministes, convergents, et capables de gérer les conflits d'état accumulés pendant la période d'isolation.
|
|||
|
|
|
|||
|
|
### Principe 5 — Opacité des Flux (Confidentialité des Métadonnées)
|
|||
|
|
|
|||
|
|
Le chiffrement de contenu est nécessaire mais insuffisant. L'architecture doit minimiser les informations révélées par les métadonnées de trafic : fréquence des échanges, volume, topologie des connexions. Des techniques de padding temporel, de trafic fictif calibré, et de routage multi-sauts doivent être employées sur les liens exposés à des observateurs potentiellement adversariaux.
|
|||
|
|
|
|||
|
|
### Principe 6 — Minimisation de la Surface d'Attaque
|
|||
|
|
|
|||
|
|
Chaque couche de l'architecture ne doit exposer que les fonctionnalités strictement nécessaires à son rôle. La couche de découverte ne doit pas avoir accès aux clés de chiffrement des transactions ; la couche de règlement ne doit pas avoir connaissance de la topologie du réseau de découverte. Cette isolation minimise l'impact d'une compromission partielle.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 2. Séparation des Couches : Architecture en Trois Plans
|
|||
|
|
|
|||
|
|
L'architecture proposée repose sur une séparation stricte en trois plans fonctionnels indépendants. Cette séparation est motivée par des exigences de sécurité mutuellement incompatibles si ces plans étaient fusionnés.
|
|||
|
|
|
|||
|
|
### Plan de Découverte
|
|||
|
|
|
|||
|
|
**Objectif** : permettre à un nœud de localiser d'autres nœuds offrant des ressources compatibles, d'évaluer leur qualité, et de maintenir un réseau de voisinage robuste.
|
|||
|
|
|
|||
|
|
**Exigences** : haute disponibilité (AP), tolérance aux partitions, faible latence de découverte, résistance aux manipulations de routage. La cohérence n'est pas critique : une vue légèrement obsolète du réseau est acceptable.
|
|||
|
|
|
|||
|
|
**Ce qui ne doit PAS figurer dans ce plan** : le contenu des transactions, les identités réelles des acteurs, les montants échangés, ou tout élément permettant d'inférer des stratégies opérationnelles.
|
|||
|
|
|
|||
|
|
### Plan de Données et Ressources
|
|||
|
|
|
|||
|
|
**Objectif** : permettre à des acteurs de décrire, offrir, découvrir et transacter des ressources (compute, stockage, données, workflows) de manière sécurisée et souveraine.
|
|||
|
|
|
|||
|
|
**Exigences** : intégrité forte (enregistrements signés), confidentialité du contenu (chiffrement bout-en-bout), souveraineté du cycle de vie (TTL contrôlé par le créateur), attestation de consommation vérifiable sans révélation du contenu.
|
|||
|
|
|
|||
|
|
**Ce qui ne doit PAS figurer dans ce plan** : le règlement monétaire (séparation de la couche applicative et de la couche financière), ni les détails de routage de la couche de découverte.
|
|||
|
|
|
|||
|
|
### Plan de Règlement Monétaire
|
|||
|
|
|
|||
|
|
**Objectif** : régler les transactions monétaires résultant de la consommation de ressources, de manière automatisée, confidentielle, et résistante à la censure.
|
|||
|
|
|
|||
|
|
**Exigences** : finalité déterministe ou quasi-déterministe, confidentialité des montants et des parties, smart contracts pour l'automatisation du règlement, gouvernance de consortium, résistance à la censure par des validateurs adversariaux.
|
|||
|
|
|
|||
|
|
**Pourquoi ces trois plans doivent rester indépendants** :
|
|||
|
|
|
|||
|
|
La couche de découverte optimise pour la disponibilité et la performance de routage — des propriétés antagonistes avec la confidentialité forte. Fusionner les couches de découverte et de données exposerait les patterns d'accès aux ressources à tout observateur participant à la DHT. La couche de règlement monétaire requiert une cohérence forte et une finalité déterministe — des propriétés incompatibles avec le profil AP de la découverte. Un seul protocole ne peut satisfaire simultanément ces exigences contradictoires.
|
|||
|
|
|
|||
|
|
Analogie : le réseau téléphonique (couche de transport) ne gère pas le réseau bancaire (couche de règlement), même si les deux transportent des informations liées à des transactions économiques.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 3. Couche de Découverte P2P
|
|||
|
|
|
|||
|
|
### 3.1 DHT Kademlia avec Espace de Noms Privé
|
|||
|
|
|
|||
|
|
La DHT Kademlia [Maymounkov & Mazières, 2002] constitue la base la plus adaptée pour la couche de découverte décentralisée. Son routage XOR en O(log n) sauts, sa robustesse au churn, et son implémentation dans de nombreux frameworks (libp2p, notamment) en font le choix le plus mature pour les réseaux P2P décentralisés à grande échelle.
|
|||
|
|
|
|||
|
|
Pour un réseau privé ou semi-privé, l'espace de noms DHT doit être isolé de la DHT globale publique. Cette isolation est réalisée par une clé de réseau (network key) distincte, empêchant la découverte croisée avec des nœuds appartenant à d'autres réseaux. S/Kademlia [Baumgart & Meinert, 2007] étend Kademlia avec des contraintes cryptographiques sur la génération des identifiants de nœuds (preuve de travail légère sur le NodeID) et des signatures sur les messages de routage, réduisant significativement les vecteurs d'empoisonnement.
|
|||
|
|
|
|||
|
|
Il n'existe pas d'alternative réaliste à Kademlia pour un réseau P2P décentralisé à cette échelle : Chord [Stoica et al., 2003] est plus simple mais moins robuste au churn ; Pastry et Tapestry présentent des propriétés similaires mais un écosystème d'implémentation plus réduit.
|
|||
|
|
|
|||
|
|
### 3.2 Transport Chiffré Multi-Protocole
|
|||
|
|
|
|||
|
|
Le Noise Protocol Framework [Perrin, 2018] fournit la primitive de transport sécurisé. Le pattern Noise_XX permet une authentification mutuelle des parties par échange de clés publiques, sans infrastructure PKI centralisée. La légèreté du framework (implémentation en quelques centaines de lignes, sans dépendance à une bibliothèque X.509) le rend particulièrement adapté aux contraintes embarquées.
|
|||
|
|
|
|||
|
|
Pour les réseaux de niveau de confiance élevée (consortium fermé), une clé pré-partagée (PSK) peut être incorporée dans le handshake Noise (pattern Noise_XXpsk), offrant une couche d'authentification supplémentaire qui garantit qu'un nœud non-membre du consortium ne peut même pas établir une connexion, réduisant drastiquement la surface d'attaque Sybil.
|
|||
|
|
|
|||
|
|
Le support multi-protocole (TCP, QUIC, WebTransport selon la disponibilité du lien) permet d'adapter le transport aux contraintes du lien physique, en particulier dans les environnements DTN où TCP peut être remplacé par des protocoles de couche bundle [Cerf et al., 2007].
|
|||
|
|
|
|||
|
|
### 3.3 Bootstrap Minimaliste
|
|||
|
|
|
|||
|
|
Le problème du premier contact est inévitable dans tout réseau décentralisé. La proposition retient une approche à trois niveaux :
|
|||
|
|
|
|||
|
|
- **Seeds codés en dur** : un ensemble minimal de nœuds de bootstrap dont les adresses et clés publiques sont incluses dans la distribution logicielle. Ces seeds sont diversifiés géographiquement et organisationnellement pour éviter un point de défaillance unique. Analogie directe avec les DNS seeds de Bitcoin et les directory authorities de Tor.
|
|||
|
|
- **DHT locale** : les nœuds maintiennent localement une table persistante de leurs derniers pairs connus, permettant de bootstrapper sans accès aux seeds dans les reconnections ultérieures.
|
|||
|
|
- **Résolution hors-bande** : pour les déploiements embarqués à haute sécurité, un mécanisme de distribution des seeds par canal hors-bande (support physique sécurisé, canal radio dédié) peut compléter les seeds réseau.
|
|||
|
|
|
|||
|
|
### 3.4 Scoring Comportemental Multidimensionnel
|
|||
|
|
|
|||
|
|
Le scoring comportemental constitue le mécanisme primaire d'évaluation de la qualité et de la fiabilité des pairs. La proposition retient une formule à sept dimensions, chacune justifiée par un vecteur de menace distinct :
|
|||
|
|
|
|||
|
|
**Dimension 1 — Ratio d'uptime (poids : 0.20)** : mesure la disponibilité historique du pair, en tenant compte des fenêtres de contact prévues. Un pair disponible 95% du temps dans ses fenêtres de contact prévues mérite une évaluation haute. Cette dimension pénalise les pairs instables ou éphémères (vecteur anti-Sybil par coût temporel).
|
|||
|
|
|
|||
|
|
**Dimension 2 — Latence normalisée (poids : 0.15)** : mesure le temps de réponse aux requêtes, normalisé par la latence attendue selon le type de lien. Cette dimension pénalise les pairs surchargés ou géographiquement distants sans que cela constitue un signal de compromission.
|
|||
|
|
|
|||
|
|
**Dimension 3 — Précision des challenges (poids : 0.25)** : des challenges cryptographiques périodiques (écho de données DHT, challenge de contenu connu) permettent de vérifier que le pair héberge réellement les données qu'il annonce. Un pair falsifiant sa capacité de stockage ou de traitement échouera sur ces challenges. C'est la dimension la plus résistante à la manipulation car elle requiert une réponse correcte à une question que l'adversaire ne peut anticiper.
|
|||
|
|
|
|||
|
|
**Dimension 4 — Diversité réseau (poids : 0.15)** : mesure la diversité des sous-réseaux IP des pairs que ce nœud connaît, favorisant les pairs bien connectés à des régions réseau variées. Cette dimension pénalise implicitement les clusters de nœuds contrôlés par un même acteur (colluseurs sur le même réseau).
|
|||
|
|
|
|||
|
|
**Dimension 5 — Taux de remplissage inverse (poids : 0.10)** : dans un contexte de marché de ressources, un pair offrant des ressources très chargées est moins utile qu'un pair offrant des ressources disponibles. Cette dimension oriente naturellement les nouveaux clients vers les pairs les moins sollicités, équilibrant la charge du réseau.
|
|||
|
|
|
|||
|
|
**Dimension 6 — Cohérence des témoins (poids : 0.10)** : les observations d'un pair par des témoins tiers (autres pairs qui l'ont récemment contacté) sont corrélées avec les observations directes. Une incohérence forte entre les témoignages et les observations directes signale une possible compromission ou une collusion localisée.
|
|||
|
|
|
|||
|
|
**Dimension 7 — Fiabilité DHT (poids : 0.05)** : mesure la probabilité que les enregistrements stockés par ce pair soient restitués correctement à des requêtes ultérieures. Cette dimension détecte les pairs qui acceptent des enregistrements sans les stocker (comportement parasite) ou qui altèrent les enregistrements confiés.
|
|||
|
|
|
|||
|
|
**Score global** :
|
|||
|
|
```
|
|||
|
|
Score = Σ(poids_i × dimension_i) × 100 ∈ [0, 100]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### 3.5 Seuil d'Éviction Dynamique selon l'Âge
|
|||
|
|
|
|||
|
|
Les nouveaux pairs ne disposent pas encore d'un historique comportemental suffisant pour être évalués équitablement. Un seuil d'éviction fixe pénaliserait systématiquement les nœuds récents, créant un réseau figé favorisant les anciens membres. La proposition retient un seuil dynamique selon l'âge du pair :
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Seuil_min(age) = min(Seuil_max, Seuil_base + Seuil_pente × age_en_jours)
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Typiquement : `Seuil_min(age) = min(80, 20 + 60 × age/24h)`, démarrant à 20% (très permissif) et atteignant 80% après 24 heures de présence continue. Ce profil permet à un nouveau pair légitime de s'établir progressivement tout en évinçant rapidement les pairs manifestement défaillants ou malveillants.
|
|||
|
|
|
|||
|
|
### 3.6 Protection Contre l'Isolement Total
|
|||
|
|
|
|||
|
|
Un invariant critique de sécurité : **le dernier pair actif d'un nœud ne peut jamais être évincé pour raison de score insuffisant seul**. Si un nœud ne dispose que d'un unique pair actif, le maintien de cette connexion, même avec un pair de score médiocre, est préférable à l'isolement complet qui rendrait le nœud aveugle et muet. L'éviction du dernier pair ne peut être déclenchée que par une preuve positive de comportement malveillant (challenge échoué, signature invalide) — non par un score passant sous un seuil.
|
|||
|
|
|
|||
|
|
### 3.7 Vérification Multi-Canal
|
|||
|
|
|
|||
|
|
La vérification de l'identité et de la qualité d'un pair par un unique canal crée une surface d'attaque exploitable par un adversaire capable de simuler parfaitement le comportement attendu sur ce canal. La proposition retient une architecture de vérification à trois canaux orthogonaux :
|
|||
|
|
|
|||
|
|
- **Challenge d'identité** : vérification cryptographique que la clé publique annoncée correspond bien au pair contacté.
|
|||
|
|
- **Challenge DHT** : vérification que le pair stocke réellement les enregistrements qu'il annonce héberger, via des requêtes sur des clés dont la valeur est connue de l'observateur.
|
|||
|
|
- **Witness query** : interrogation de pairs tiers sur leur expérience récente avec le pair évalué.
|
|||
|
|
|
|||
|
|
La vérification simultanément cohérente sur ces trois canaux orthogonaux requiert un niveau de sophistication adversariale croissant de manière exponentielle avec le nombre de canaux vérifiés, rendant la tromperie coordonnée prohibitivement coûteuse.
|
|||
|
|
|
|||
|
|
### 3.8 Gossip Sub pour la Propagation d'Événements
|
|||
|
|
|
|||
|
|
Les événements d'appartenance (arrivée, départ, mise à jour de score significative) sont propagés par un mécanisme de gossip sub — diffusion épidémique structurée de type infection-style [Das et al., 2002]. Ce mécanisme garantit une convergence en O(log n) étapes avec haute probabilité, sans coordination centrale. La propagation épidémique est robuste au churn et tolère l'absence temporaire de nœuds.
|
|||
|
|
|
|||
|
|
Pour les environnements hostiles, le gossip peut être limité aux paires de pairs avec une clé de chiffrement commune (intra-consortium), empêchant la fuite d'informations topologiques vers des observateurs extérieurs.
|
|||
|
|
|
|||
|
|
### 3.9 Adaptation DTN/Spatial
|
|||
|
|
|
|||
|
|
Les adaptations suivantes sont indispensables pour le contexte DTN :
|
|||
|
|
|
|||
|
|
- **Stockage-et-retransmission** : les messages de découverte non livrables (pair inaccessible) sont stockés localement et retransmis lors des prochaines fenêtres de contact, selon le modèle de la RFC 4838 [Cerf et al., 2007].
|
|||
|
|
- **TTL adaptatifs** : le TTL des enregistrements DHT est paramétré en fonction du délai de propagation prévisible dans le réseau. Pour un satellite LEO avec une fenêtre de contact de 15 minutes toutes les 90 minutes, les TTL doivent être d'au moins 90 minutes pour survivre à un cycle orbital complet.
|
|||
|
|
- **Heartbeats asynchrones** : en l'absence de connectivité continue, les heartbeats sont accumulés localement et émis en batch lors des fenêtres de contact, avec des timestamps signés permettant la reconstitution de l'historique d'uptime.
|
|||
|
|
- **State snapshots** : l'état complet du réseau de voisinage est sérialisé périodiquement sur le stockage local, permettant une reprise sans perte après une déconnexion prolongée.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 4. Couche de Données et Ressources
|
|||
|
|
|
|||
|
|
### 4.1 Records Signés avec Expiration Courte
|
|||
|
|
|
|||
|
|
Chaque enregistrement dans la DHT porte la signature de son créateur (clé privée ECDSA ou Ed25519) et un timestamp d'expiration. L'expiration courte (TTL typiquement entre 5 minutes et quelques heures selon le type de ressource) garantit l'auto-invalidation des enregistrements obsolètes sans mécanisme de suppression explicite. Le créateur est responsable du renouvellement périodique de ses enregistrements actifs.
|
|||
|
|
|
|||
|
|
Pour le contexte DTN, les TTL sont adaptés au profil de connectivité prévisible : un nœud satellite qui passe en dehors de la couverture sol pendant 2 heures doit avoir des TTL d'au moins 2 heures pour ses enregistrements critiques.
|
|||
|
|
|
|||
|
|
### 4.2 Tombstones Signés pour la Révocation Propre
|
|||
|
|
|
|||
|
|
La suppression explicite d'un enregistrement avant son expiration naturelle passe par un tombstone signé — un enregistrement spécial portant la clé de l'enregistrement révoqué, le timestamp de révocation, et la signature du créateur. Les tombstones sont propagés par gossip et stockés temporairement dans la DHT pour prévenir la réapparition de l'enregistrement révoqué (replay attack).
|
|||
|
|
|
|||
|
|
La durée de vie d'un tombstone doit être supérieure à la durée de vie maximale de l'enregistrement qu'il révoque, pour garantir que les nœuds qui n'ont pas encore vu la révocation ne réacceptent pas un replay de l'enregistrement original.
|
|||
|
|
|
|||
|
|
### 4.3 Index Secondaires dans la DHT
|
|||
|
|
|
|||
|
|
Pour permettre la découverte de ressources selon plusieurs critères (par type de ressource, par zone géographique, par niveau de confiance minimal requis), des index secondaires sont maintenus dans la DHT sous des clés dérivées des attributs d'indexation. Un enregistrement principal décrivant une ressource de compute est par exemple indexé sous `hash("compute")`, `hash("zone:LEO-1")`, et `hash("trust:consortium-A")`.
|
|||
|
|
|
|||
|
|
### 4.4 Chiffrement de Contenu Bout-en-Bout
|
|||
|
|
|
|||
|
|
Pour les données sensibles, la DHT ne doit stocker que des enveloppes chiffrées. Le payload de l'enregistrement est chiffré avec une clé symétrique connue uniquement des parties autorisées (clé de consortium ou clé dérivée d'un échange Diffie-Hellman). La DHT agit comme un système de stockage aveugle, incapable d'inférer le contenu des enregistrements qu'elle héberge.
|
|||
|
|
|
|||
|
|
Ce principe garantit que même un adversaire contrôlant une région de la DHT ne peut accéder au contenu des enregistrements, seulement à leurs métadonnées (clé DHT, créateur, expiration).
|
|||
|
|
|
|||
|
|
### 4.5 Attestation de Consommation par Zero-Knowledge Proofs
|
|||
|
|
|
|||
|
|
Le problème de l'oracle (comment prouver qu'une ressource a été réellement consommée sans révéler ni le contenu ni l'identité de l'initiateur) est adressé par les preuves à divulgation nulle de connaissance (ZK-proofs). Goldwasser, Micali et Rackoff [Goldwasser et al., 1989] ont formalisé ce paradigme ; les constructions modernes basées sur des arguments non-interactifs à divulgation nulle (zk-SNARKs [Groth, 2016]) permettent de prouver la bonne exécution d'un calcul en O(1) de vérification, quelle que soit la complexité du calcul.
|
|||
|
|
|
|||
|
|
Pour un marché de ressources, une attestation ZK permet à un consommateur de prouver à un smart contract qu'il a reçu et vérifié un résultat de calcul conforme à sa spécification, sans révéler ni le résultat lui-même ni les paramètres d'entrée.
|
|||
|
|
|
|||
|
|
### 4.6 Pub/Sub pour les Événements Applicatifs
|
|||
|
|
|
|||
|
|
Les événements applicatifs (disponibilité d'une ressource, completion d'un workflow, alerte de capacité) sont propagés via un mécanisme pub/sub indépendant de la couche de découverte. Ce mécanisme doit être léger, tolérant aux déconnexions temporaires (accumulation de messages pendant les périodes hors-ligne), et ne pas exposer la topologie du réseau de souscription.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 5. Couche de Règlement Monétaire et Blockchain
|
|||
|
|
|
|||
|
|
### 5.1 Positionnement Transactionnel
|
|||
|
|
|
|||
|
|
La blockchain n'est pas la couche de découverte, ni la couche de données. Elle intervient exclusivement pour le règlement monétaire des transactions de ressources, après que ces ressources ont été consommées et attestées. Ce positionnement est fondamental : confondre la blockchain avec l'infrastructure de découverte ou de données créerait des couplages qui dégradent à la fois les performances (latence blockchain incompatible avec la découverte en temps réel) et la confidentialité (toute donnée sur la blockchain est potentiellement publique).
|
|||
|
|
|
|||
|
|
La blockchain règle les transactions APRÈS leur exécution, sur la base d'attestations cryptographiques de consommation. Elle n't pas besoin de connaître le contenu des ressources échangées, ni les identités des parties au-delà de leurs adresses blockchain (qui peuvent être pseudonymes ou chiffrées selon la solution choisie).
|
|||
|
|
|
|||
|
|
### 5.2 Exigences Non-Négociables pour la Blockchain Éligible
|
|||
|
|
|
|||
|
|
Les exigences suivantes sont dérivées des contraintes du contexte cible et constituent des critères d'exclusion pour les solutions inadaptées :
|
|||
|
|
|
|||
|
|
| Exigence | Justification |
|
|||
|
|
|---|---|
|
|||
|
|
| Confidentialité des transactions (montants et parties) | Tout observateur externe ne doit pouvoir inférer ni le volume des échanges, ni les partenariats entre acteurs |
|
|||
|
|
| Souveraineté (pas de fuite vers observateur externe) | Même les métadonnées de la blockchain ne doivent pas révéler d'informations stratégiques |
|
|||
|
|
| Finalité rapide (< 30s idéalement, < 5 min acceptable) | Compatibilité avec les fenêtres de contact DTN limitées |
|
|||
|
|
| Smart contracts pour automatisation du règlement | Automatisation du paiement conditionnel à l'attestation de consommation [Szabo, 1997 ; Wood, 2014] |
|
|||
|
|
| Résistance à la censure | Un validateur adversarial ne doit pas pouvoir bloquer unilatéralement une transaction |
|
|||
|
|
| Gouvernabilité de consortium | Admission, révocation, rotation des validateurs sans redémarrage du réseau |
|
|||
|
|
| Faible empreinte énergétique | Contrainte stricte pour les nœuds embarqués (Proof of Work exclu) |
|
|||
|
|
|
|||
|
|
### 5.3 Analyse des Blockchains Éligibles
|
|||
|
|
|
|||
|
|
| Blockchain | Confidentialité | Finalité | Smart Contracts | Consortium | Énergie | Maturité | Contexte GARDEN |
|
|||
|
|
|---|---|---|---|---|---|---|---|
|
|||
|
|
| Ethereum (L1) | ✗ (transparence totale) | △ (12s, probabiliste) | ✓✓ (EVM, très mature) | ✗ (public) | ✗ (PoS OK, mais L1 lourd) | ✓✓ | Inadapté seul |
|
|||
|
|
| Ethereum L2 ZK (Aztec, zkSync) | ✓✓ (ZK-rollup) | △ (L2 fast, L1 proof lente) | ✓ (en développement) | △ | △ | △ (jeune) | Prometteur, encore immature |
|
|||
|
|
| Aztec Network | ✓✓ (ZK natif chiffré) | △ | ✓ (Noir language) | △ | ✓ | △ (en développement actif) | Très intéressant pour confidentialité, maturité insuffisante 2026 |
|
|||
|
|
| Secret Network | ✓✓ (TEE chiffrés) | ✓ (Tendermint ~6s) | ✓✓ (CosmWasm confidentiel) | ✓ (Cosmos zones) | ✓✓ | ✓ | Bon candidat consortium |
|
|||
|
|
| Oasis Network | ✓✓ (TEE + ParaTime) | ✓ (Tendermint) | ✓✓ (EVM confidentiel) | ✓ | ✓✓ | ✓ | Très adapté embarqué + smart contracts |
|
|||
|
|
| Zcash | ✓✓ (ZK-SNARKs, shielded) | △ (PoW, ~75s) | ✗ (Script limité) | ✗ (public) | ✗ (PoW) | ✓✓ | Excellent paiements confidentiels, insuffisant smart contracts |
|
|||
|
|
| Monero | ✓✓ (RingCT, Ring Sig) | △ (PoW, ~2min) | ✗ | ✗ (public) | ✗ (PoW) | ✓✓ | Idem Zcash, moins adapté |
|
|||
|
|
| Aleo | ✓✓ (ZK natif, Leo language) | ✓ (PoS, ~15s) | ✓ (ZK-native execution) | △ | ✓✓ | △ (mainnet récent) | Très prometteur, écosystème jeune |
|
|||
|
|
| Hyperledger Fabric | ✓✓ (canaux privés) | ✓✓ (déterministe, Raft/PBFT) | ✓✓ (chaincode mature) | ✓✓ (MSP, canaux) | ✓✓ | ✓✓ | Idéal consortium fermé |
|
|||
|
|
| Cosmos SDK + IBC | △ (dépend de la zone) | ✓✓ (Tendermint ~6s) | ✓ (CosmWasm) | ✓✓ (zones souveraines) | ✓✓ | ✓✓ | Excellente base multi-consortium |
|
|||
|
|
| Polkadot / Substrate | △ | ✓ (GRANDPA ~12s) | ✓ (ink!, EVM via frontier) | ✓✓ (parachains) | ✓✓ | ✓ | Adapté multi-consortium, complexe |
|
|||
|
|
|
|||
|
|
**Analyse détaillée des blockchains les plus pertinentes** :
|
|||
|
|
|
|||
|
|
**Hyperledger Fabric** [Androulaki et al., 2018] est une blockchain permissionnée conçue pour les consortiums d'entreprises. Son architecture modulaire (orderers, peers, MSP) permet une gouvernance fine des membres du consortium. Les canaux privés permettent à un sous-ensemble de membres d'effectuer des transactions invisibles aux autres membres. La finalité est déterministe (pas de forks possibles avec Raft ou PBFT), propriété critique pour le contexte DTN où la réconciliation de forks est difficile. Son principal défaut est l'absence de résistance trustless : la confiance dans les MSP (Membership Service Providers) est requise, ce qui convient aux consortiums fermés mais rend la solution inadaptée aux échanges inter-consortium entre adversaires potentiels.
|
|||
|
|
|
|||
|
|
**Cosmos SDK + IBC** [Kwon & Buchman, 2016] offre une architecture de zones souveraines interconnectées via le protocole IBC (Inter-Blockchain Communication). Chaque zone peut être configurée indépendamment (algorithme de consensus, gouvernance, smart contracts), permettant des niveaux de sécurité différenciés selon le contexte. Le consensus Tendermint BFT [Buchman, 2016] offre une finalité déterministe en environ 6 secondes — compatible avec les contraintes DTN raisonnables. L'absence de confidentialité native est le principal défaut : les transactions IBC sont visibles dans les logs des deux zones impliquées.
|
|||
|
|
|
|||
|
|
**Secret Network** utilise des enclaves TEE (Trusted Execution Environment) Intel SGX pour exécuter les smart contracts dans un environnement chiffré. Les entrées, les sorties, et l'état des smart contracts sont chiffrés pour les validateurs eux-mêmes — seul le code est public. Cette propriété est exceptionnelle pour un contexte hostile. La principale limitation est la dépendance à Intel SGX, une technologie matérielle présentant des vulnérabilités de canal latéral documentées [Costan & Devadas, 2016]. La compatibilité Cosmos offre une interopérabilité avec un écosystème large.
|
|||
|
|
|
|||
|
|
**Zcash** [Ben-Sasson et al., 2014 ; Hopwood et al., 2016] utilise les zk-SNARKs pour permettre des transactions shielded dont les montants et les adresses sont cryptographiquement cachés. C'est la solution la plus mature pour les paiements confidentiels purs, sans dépendance matérielle (contrairement aux TEE). Sa limitation principale est l'absence de smart contracts expressifs : le langage Script de Zcash ne permet pas d'automatiser le règlement conditionnel requis pour un marché de ressources complexe.
|
|||
|
|
|
|||
|
|
**Oasis Network** [Oasis Labs, 2020] combine TEE et blockchain pour offrir des "ParaThreads" confidentiels : des environnements d'exécution chiffrés où les calculs se déroulent à l'abri des validateurs. L'EVM confidentiel (Sapphire ParaTime) permet d'exécuter des smart contracts Solidity avec confidentialité des états internes. La compatibilité avec l'écosystème Cosmos et l'EVM en fait un candidat particulièrement polyvalent.
|
|||
|
|
|
|||
|
|
### 5.4 Recommandation Architecturale
|
|||
|
|
|
|||
|
|
La proposition retient une architecture hybride à deux niveaux :
|
|||
|
|
|
|||
|
|
**Niveau 1 — Intra-consortium** : Hyperledger Fabric ou une zone Cosmos permissionnée. La gouvernance est assurée par le consortium via les MSP (Fabric) ou la gouvernance on-chain (Cosmos). Les transactions intra-consortium bénéficient de canaux privés (Fabric) ou d'une confidentialité applicative. La finalité déterministe garantit l'absence de forks. Ce niveau traite 95%+ des transactions dans un déploiement opérationnel normal.
|
|||
|
|
|
|||
|
|
**Niveau 2 — Inter-consortium et règlement public** : Secret Network ou Oasis Network pour les transactions entre acteurs de consortiums distincts, bénéficiant de smart contracts confidentiels. Les attestations de consommation de ressources sont soumises on-chain comme ZK-proofs hors-chaîne, permettant de prouver la bonne exécution sans révéler le contenu des calculs [Groth, 2016].
|
|||
|
|
|
|||
|
|
**Gouvernance** : chaque consortium maintient une structure de gouvernance multi-sig avec seuil de quorum configurable. Les décisions d'admission et d'exclusion de membres requièrent un quorum configurable (typiquement 2/3) pour résister aux attaques de corruption minoritaire.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 6. Verrous Conceptuels et Technologiques
|
|||
|
|
|
|||
|
|
### Verrou 1 — Identité sans Autorité Centrale (TOFU)
|
|||
|
|
|
|||
|
|
**Problème** : Comment établir qu'une clé publique appartient bien à l'acteur qu'elle prétend représenter, sans autorité de certification centrale ? Le paradigme TOFU (Trust On First Use) accepte la clé lors du premier contact et avertit en cas de changement — solution pragmatique mais vulnérable à l'interception du premier contact.
|
|||
|
|
|
|||
|
|
**Solutions** : Les identifiants décentralisés (DID) définis par la spécification W3C [W3C, 2022] permettent à des acteurs de créer des identités auto-certifiées ancrées dans une blockchain ou un réseau de confiance distribué, sans dépendance à une autorité centrale. Les identifiants libp2p (PeerID dérivé de la clé publique) offrent une auto-certification primitive.
|
|||
|
|
|
|||
|
|
**Challenge résiduel** : L'ancrage d'une identité DID dans une blockchain publique révèle l'existence de l'identité à tout observateur. Pour un contexte hostile, des identités éphémères rotatoires avec des mécanismes de reconnaissance hors-bande constituent une alternative, au prix d'une complexité opérationnelle plus élevée.
|
|||
|
|
|
|||
|
|
### Verrou 2 — Bootstrap Trustless
|
|||
|
|
|
|||
|
|
**Problème** : Le premier contact avec le réseau requiert de connaître au moins un pair de confiance. Ces seeds constituent un ancre de confiance qui ne peut être supprimée — elle peut seulement être diversifiée et distribuée pour réduire le risque de compromission partielle.
|
|||
|
|
|
|||
|
|
**Solutions** : Diversification des seeds (géographique, organisationnelle, technologique). Distribution des seeds par canal hors-bande pour les environnements à haute sécurité. DHT locale persistante pour les reconnexions.
|
|||
|
|
|
|||
|
|
**Challenge résiduel** : Aucun système sans seed codés en dur ou sans canal hors-bande de confiance ne peut bootstrapper de manière véritablement trustless. Les seeds constituent nécessairement une ancre de confiance minimale.
|
|||
|
|
|
|||
|
|
### Verrou 3 — Résistance Sybil sans Coût Cryptoéconomique
|
|||
|
|
|
|||
|
|
**Problème** : Douceur [Douceur, 2002] a démontré que la résistance Sybil est impossible sans coût d'entrée ou autorité centrale. Pour les réseaux ouverts en environnement hostile, ni la PSK organisationnelle ni le scoring comportemental ne constituent des solutions complètes : la PSK est efficace mais requiert une coordination hors-bande pour chaque nouvel entrant ; le scoring peut être manipulé sur le long terme par un adversaire patient.
|
|||
|
|
|
|||
|
|
**Solutions** : PSK organisationnelle pour les réseaux fermés. Scoring comportemental multidimensionnel comme couche de défense secondaire. Pour les réseaux ouverts, un dépôt cryptoéconomique (stake on-chain) comme coût d'entrée minimum.
|
|||
|
|
|
|||
|
|
**Challenge résiduel** : Les réseaux entièrement ouverts et hostiles sans coût d'entrée cryptoéconomique restent vulnérables à des attaques Sybil patient et bien financées.
|
|||
|
|
|
|||
|
|
### Verrou 4 — Cohérence sans Consensus Fort (CAP)
|
|||
|
|
|
|||
|
|
**Problème** : Le théorème CAP [Brewer, 2000 ; Gilbert & Lynch, 2002] impose un choix entre cohérence et disponibilité lors d'un partitionnement. Pour la couche de découverte, choisir CP rendrait le système indisponible lors des partitions DTN fréquentes.
|
|||
|
|
|
|||
|
|
**Solution** : Choix délibéré du profil AP pour la découverte (cohérence éventuelle, disponibilité prioritaire), CP pour le règlement blockchain (cohérence forte, disponibilité conditionnelle au quorum). Les conflits d'état lors de la réunification sont résolus par Last-Write-Wins ou par vecteurs d'horloge selon la criticité des enregistrements.
|
|||
|
|
|
|||
|
|
**Challenge résiduel** : La cohérence éventuelle autorise des fenêtres temporaires d'état incohérent qui peuvent être exploitées par un adversaire contrôlant l'instant de la réunification.
|
|||
|
|
|
|||
|
|
### Verrou 5 — Détection de Panne sans Oracle (FLP)
|
|||
|
|
|
|||
|
|
**Problème** : Fischer, Lynch et Paterson [Fischer, Lynch & Paterson, 1985] ont démontré qu'en présence d'asynchronisme, aucun algorithme déterministe ne peut distinguer un pair défaillant d'un pair lent. Toute détection de panne est donc probabiliste et sujette à des faux positifs.
|
|||
|
|
|
|||
|
|
**Solution** : Le protocole SWIM [Das et al., 2002] offre une approche infection-style avec gestion des suspicions (un pair suspecté d'être défaillant n'est pas immédiatement exclu mais marqué comme suspect, et la confirmation de sa panne requiert la convergence de plusieurs observations indépendantes). Cette approche est adaptée aux réseaux DTN où les faux positifs de détection de panne sont fréquents.
|
|||
|
|
|
|||
|
|
**Challenge résiduel** : Dans les réseaux DTN à très haute latence, les délais de confirmation de panne peuvent atteindre plusieurs cycles orbitaux, pendant lesquels un pair défaillant (ou malveillant) reste actif dans les tables de voisinage.
|
|||
|
|
|
|||
|
|
### Verrou 6 — Confidentialité des Transactions sur Chaîne Publique
|
|||
|
|
|
|||
|
|
**Problème** : La transparence des blockchains publiques est structurellement antagoniste à la confidentialité opérationnelle. Même les blockchains pseudonymes permettent la reconstruction partielle des graphes de transactions [Meiklejohn et al., 2013].
|
|||
|
|
|
|||
|
|
**Solutions** : ZK-SNARKs [Ben-Sasson et al., 2014] pour masquer cryptographiquement les montants et les adresses. TEE (Trusted Execution Environment) pour l'exécution confidentielle des smart contracts [Oasis Labs, 2020]. Blockchains permissionnées avec canaux privés [Androulaki et al., 2018].
|
|||
|
|
|
|||
|
|
**Challenge résiduel** : Les solutions ZK sont encore en cours de maturation pour les smart contracts complexes. Les solutions TEE présentent des dépendances matérielles avec des vulnérabilités de canal latéral documentées. Les blockchains permissionnées requièrent une confiance dans les opérateurs du réseau.
|
|||
|
|
|
|||
|
|
### Verrou 7 — DTN et Transactions Intermittentes
|
|||
|
|
|
|||
|
|
**Problème** : Les blockchains classiques supposent une connectivité continue entre validateurs. Dans un réseau DTN, un validateur peut être absent pendant plusieurs heures, bloquant l'atteinte du quorum et donc le traitement des transactions.
|
|||
|
|
|
|||
|
|
**Solutions** :
|
|||
|
|
- **State channels** : deux parties pré-engagent des fonds dans un canal off-chain et échangent des signatures hors-chaîne pendant une période prolongée, ne soumettant le résultat final on-chain qu'à la clôture du canal. Cette approche tolère des périodes de déconnexion arbitrairement longues.
|
|||
|
|
- **Optimistic rollups** : les transactions sont soumises on-chain avec une fenêtre de contestation. En l'absence de contestation, la transaction est finalisée. Adapté aux environnements à faible fraude mais à connectivité intermittente.
|
|||
|
|
- **Signature différée** : les transactions sont signées localement avec un timestamp, accumulées pendant la période hors-ligne, et soumises en batch lors de la prochaine fenêtre de connexion. Le smart contract vérifie la validité temporelle des signatures.
|
|||
|
|
|
|||
|
|
**Challenge résiduel** : Les state channels requièrent une connexion initiale pour l'engagement des fonds. Les optimistic rollups introduisent des fenêtres de contestation de plusieurs heures — compatibles DTN mais augmentant la latence de finalité effective.
|
|||
|
|
|
|||
|
|
### Verrou 8 — Oracle et Preuve de Consommation Réelle
|
|||
|
|
|
|||
|
|
**Problème** : Szabo [Szabo, 1997] a identifié la difficulté fondamentale d'ancrer des contrats sur des événements du monde réel. Un smart contract de règlement de ressources doit vérifier qu'un calcul s'est réellement exécuté, que des données ont été réellement livrées — mais un smart contract est exécuté dans un environnement blockchain isolé du monde extérieur.
|
|||
|
|
|
|||
|
|
**Solutions** :
|
|||
|
|
- **TEE attestations** : un calcul exécuté dans une enclave Intel SGX ou ARM TrustZone génère une attestation cryptographique signée par le microprocesseur lui-même, prouvant que le code spécifié s'est exécuté dans un environnement sécurisé.
|
|||
|
|
- **ZK-proof d'exécution** : un ZKP prouve la bonne exécution d'un programme sur des entrées données sans révéler ni les entrées ni les sorties. Des systèmes comme zkEVM et les ZKVM expérimentaux permettent cette approche pour des programmes arbitraires [Groth, 2016].
|
|||
|
|
- **Challenge-response** : le consommateur soumet une preuve interactive (échantillonnage aléatoire de résultats vérifiables) que le fournisseur ne peut produire qu'en ayant réellement exécuté le calcul.
|
|||
|
|
|
|||
|
|
**Challenge résiduel** : Les TEE présentent des vulnérabilités de canal latéral [Costan & Devadas, 2016]. Les ZK-proofs d'exécution générique restent coûteux à générer pour des programmes complexes.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 7. Gestion des Consortiums et Confiance Relative
|
|||
|
|
|
|||
|
|
### 7.1 Modèle de Confiance Relative (Non-Binaire)
|
|||
|
|
|
|||
|
|
La confiance accordée à un pair est formalisée comme un vecteur multidimensionnel de scores, agrégé en un score scalaire dans [0, 100] :
|
|||
|
|
|
|||
|
|
```
|
|||
|
|
Confiance(pair, t) = f(uptime_ratio(t), challenge_precision(t),
|
|||
|
|
witness_coherence(t), age(pair),
|
|||
|
|
diversity_contribution(t))
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Ce score est mis à jour à chaque interaction et décroît graduellement en l'absence d'observations récentes (décroissance exponentielle avec demi-vie paramétrable). Un pair absent depuis longtemps n'est pas nécessairement malveillant — son score se dégrade pour refléter l'incertitude croissante sur son état.
|
|||
|
|
|
|||
|
|
Un modèle binaire échoue parce qu'il ignore cette incertitude temporelle : un pair qui obtient le statut "de confiance" le conserve indéfiniment, même si son comportement récent est suspect. Le modèle continu à décroissance temporelle force une réévaluation permanente.
|
|||
|
|
|
|||
|
|
### 7.2 Architecture de Consortium à Trois Niveaux
|
|||
|
|
|
|||
|
|
**Niveau 1 — Consortium PSK** : Pairs partageant une clé pré-partagée (Pre-Shared Key) distribuée par voie organisationnelle sécurisée. La PSK est incorporée dans le handshake Noise, garantissant que seuls les membres du consortium peuvent établir des connexions dans cet espace. La confiance a priori est élevée (score initial : 70/100). Ce niveau correspond aux pairs appartenant à la même organisation ou unité opérationnelle.
|
|||
|
|
|
|||
|
|
**Niveau 2 — Consortium à Attestation** : Pairs d'organisations alliées disposant d'une attestation signée par un membre de niveau 1. L'attestation contient la clé publique du pair, sa période de validité, et les ressources auxquelles il est autorisé à accéder. La confiance a priori est modérée (score initial : 40/100). Ce niveau correspond aux partenaires de coalition.
|
|||
|
|
|
|||
|
|
**Niveau 3 — Réseau Ouvert** : Pairs sans attestation ni PSK. La confiance initiale est nulle (score : 0/100) et ne peut augmenter que par accumulation d'observations comportementales positives sur une période prolongée. L'accès aux ressources critiques est restreint jusqu'à ce que le score dépasse un seuil configurable.
|
|||
|
|
|
|||
|
|
### 7.3 Révocation et Propagation de Méfiance
|
|||
|
|
|
|||
|
|
La révocation d'un pair est propagée par un tombstone signé par un membre de niveau 1, diffusé par gossip épidémique [Das et al., 2002]. Tous les pairs recevant ce tombstone mettent immédiatement le score du pair révoqué à zéro et le placent sur une liste noire temporaire. La liste noire est elle-même signée et distribuée avec un TTL configurable, permettant une réhabilitation éventuelle après révocation temporaire.
|
|||
|
|
|
|||
|
|
Pour les situations de compromission active (clé privée extraite), le protocole de révocation d'urgence est initié simultanément par plusieurs membres de niveau 1 pour éviter qu'un adversaire contrôlant un unique membre puisse bloquer la révocation.
|
|||
|
|
|
|||
|
|
### 7.4 Consortiums Dynamiques
|
|||
|
|
|
|||
|
|
L'admission d'un nouveau membre est effectuée sans redémarrage du réseau : la nouvelle attestation est diffusée via gossip, et les membres existants commencent à accepter des connexions du nouveau membre dès réception de l'attestation valide. La rotation des PSK suit un calendrier prédéfini avec une fenêtre de grâce permettant la transition progressive (ancienne et nouvelle PSK acceptées simultanément pendant une fenêtre configurable de 24 à 72 heures).
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## 8. Adaptations Indispensables pour le Contexte Spatial/Embarqué
|
|||
|
|
|
|||
|
|
### 8.1 Protocoles DTN-Compatibles
|
|||
|
|
|
|||
|
|
Tous les protocoles de la couche de découverte doivent être adaptés pour tolérer des latences aller-retour de plusieurs minutes et des interruptions de connectivité de plusieurs heures. Les timeouts TCP standard (généralement inférieurs à quelques minutes) sont remplacés par des délais configurables compatibles avec les orbites prévisibles. Les messages critiques sont acquittés avec retransmission exponentielle.
|
|||
|
|
|
|||
|
|
### 8.2 Minimisation des Échanges Verbeux
|
|||
|
|
|
|||
|
|
Les protocoles verbeux (abondance de handshakes, de messages de keepalive, de synchronisations de tables de routage) sont remplacés par des protocoles binaires compacts (Protocol Buffers, CBOR) avec compression différentielle. La fréquence des messages de maintenance est adaptée dynamiquement à la bande passante disponible : sur un lien satellite à 64 kbps, le heartbeat périodique est espacé de plusieurs minutes, non de quelques secondes.
|
|||
|
|
|
|||
|
|
### 8.3 Signature Différée et Soumission Batch
|
|||
|
|
|
|||
|
|
Dans les environnements DTN, les transactions sont signées localement avec un timestamp et accumulées dans une file de persistance locale. Lors des fenêtres de connexion disponibles, elles sont soumises en batch à la couche de règlement. Le smart contract vérifie que le timestamp de signature se situe dans une fenêtre acceptable et que le nonce est unique (prévention des replays).
|
|||
|
|
|
|||
|
|
### 8.4 Module de Sécurité Matérielle
|
|||
|
|
|
|||
|
|
La clé privée principale de chaque nœud est hébergée dans un module de sécurité matérielle (HSM) ou une enclave sécurisée (ARM TrustZone, RISC-V Keystone) rendant son extraction physique difficile même en cas de capture du nœud. Les opérations cryptographiques (signature, déchiffrement) sont déléguées au module HSM sans que la clé privée ne quitte jamais l'enclave.
|
|||
|
|
|
|||
|
|
### 8.5 Mode Autonome Complet
|
|||
|
|
|
|||
|
|
Chaque nœud doit être capable d'opérer en mode complètement autonome (zéro connexion réseau) pendant des durées pouvant atteindre plusieurs jours, en maintenant un état cohérent de ses ressources locales, en traitant les requêtes locales, et en accumulant les transactions en attente de règlement. La resynchronisation après reconnexion est déterministe et complète, résolvant les conflits d'état par un mécanisme de résolution configuré à l'avance.
|
|||
|
|
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
## Références Bibliographiques
|
|||
|
|
|
|||
|
|
**[Androulaki et al., 2018]** Androulaki, E., Barger, A., Bortnikov, V., Cachin, C., Christidis, K., De Caro, A., Enyeart, D., Ferris, C., Laventman, G., Manevich, Y., Muralidharan, S., Murthy, C., Nguyen, B., Sethi, M., Singh, G., Smith, K., Sorniotti, A., Stathakopoulou, C., Vukolic, M., Cocco, S. W., & Yellick, J. (2018). Hyperledger Fabric: a distributed operating system for permissioned blockchains. In *Proceedings of the 13th EuroSys Conference*, article 30.
|
|||
|
|
|
|||
|
|
**[Baumgart & Meinert, 2007]** Baumgart, I., & Meinert, S. (2007). S/Kademlia: A practicable approach towards secure key-based routing. In *Proceedings of the 2007 International Conference on Parallel and Distributed Systems (ICPADS)*, pp. 1–8.
|
|||
|
|
|
|||
|
|
**[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 Symposium on Security and Privacy (S&P)*, pp. 459–474.
|
|||
|
|
|
|||
|
|
**[Brewer, 2000]** Brewer, E. A. (2000). Towards robust distributed systems. In *Proceedings of the 19th Annual ACM Symposium on Principles of Distributed Computing (PODC)*, pp. 7.
|
|||
|
|
|
|||
|
|
**[Buchman, 2016]** Buchman, E. (2016). *Tendermint: Byzantine Fault Tolerance in the Age of Blockchains*. M.Sc. Thesis, University of Guelph.
|
|||
|
|
|
|||
|
|
**[Cerf et al., 2007]** Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., & Weiss, H. (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., Goldfeder, S., Kell, T., Li, Y., Zhao, X., Bentov, I., Breidenbach, L., & Juels, A. (2020). Flash Boys 2.0: Frontrunning in Decentralized Exchanges, Miner Extractable Value, and Consensus Instability. In *Proceedings of the 2020 IEEE Symposium on Security and Privacy (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 the 2002 International Conference on Dependable Systems and Networks (DSN)*, pp. 303–312.
|
|||
|
|
|
|||
|
|
**[Douceur, 2002]** Douceur, J. R. (2002). The Sybil Attack. In *Proceedings of the 1st International Workshop on Peer-to-Peer Systems (IPTPS)*, 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. *Journal of the ACM (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.
|
|||
|
|
|
|||
|
|
**[Groth, 2016]** Groth, J. (2016). On the size of pairing-based non-interactive arguments. In *Proceedings of the 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques (EUROCRYPT 2016)*, LNCS 9666, pp. 305–326.
|
|||
|
|
|
|||
|
|
**[Hopwood et al., 2016]** Hopwood, D., Bowe, S., Hornby, T., & Wilcox, N. (2016). *Zcash Protocol Specification*. Electric Coin Company. https://zips.z.cash/protocol/protocol.pdf
|
|||
|
|
|
|||
|
|
**[Kwon & Buchman, 2016]** Kwon, J., & Buchman, E. (2016). *Cosmos: A Network of Distributed Ledgers*. Whitepaper. https://v1.cosmos.network/resources/whitepaper
|
|||
|
|
|
|||
|
|
**[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., Pomarole, M., Jordan, G., Levchenko, K., McCoy, D., Voelker, G. M., & Savage, S. (2013). A Fistful of Bitcoins: Characterizing Payments Among Men with No Names. 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
|
|||
|
|
|
|||
|
|
**[Oasis Labs, 2020]** Oasis Network (2020). *Oasis Network Primer*. Oasis Labs. https://oasisprotocol.org/primer
|
|||
|
|
|
|||
|
|
**[Perrin, 2018]** Perrin, T. (2018). *The Noise Protocol Framework*. https://noiseprotocol.org/noise.pdf
|
|||
|
|
|
|||
|
|
**[Stoica et al., 2003]** Stoica, I., Morris, R., Liben-Nowell, D., Karger, D. R., Kaashoek, M. F., Dabek, F., & Balakrishnan, H. (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: A Compact Accumulator-Based (Linkable Ring Signature) Protocol for Blockchain Cryptocurrency Monero. 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*. W3C Recommendation. https://www.w3.org/TR/did-core/
|
|||
|
|
|
|||
|
|
**[Wood, 2014]** Wood, G. (2014). *Ethereum: A Secure Decentralised Generalised Transaction Ledger*. Ethereum Yellow Paper. https://ethereum.github.io/yellowpaper/paper.pdf
|
|||
|
|
|
|||
|
|
**[Wood, 2016]** Wood, G. (2016). *Polkadot: Vision for a Heterogeneous Multi-Chain Framework*. Whitepaper. https://polkadot.network/PolkaDotPaper.pdf
|