455 lines
56 KiB
Markdown
455 lines
56 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), 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), 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), 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 (résultat FLP) 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 : 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
|
||
|
||
La couche de découverte permet à un nœud de localiser des pairs offrant des ressources compatibles, d'évaluer leur qualité, et de maintenir un réseau de voisinage robuste. Elle adopte délibérément le profil AP du théorème CAP, disponibilité prioritaire sur cohérence, car une vue légèrement obsolète du réseau est acceptable là où une indisponibilité totale lors d'une partition ne l'est pas. Cette couche ne doit porter aucune information transactionnelle : ni contenu des échanges, ni identités réelles, ni montants. Toute information permettant d'inférer des stratégies opérationnelles depuis la DHT constitue une fuite de confidentialité, pas un problème de découverte.
|
||
|
||
### Plan de Données et Ressources
|
||
|
||
Ce plan prend en charge la description, l'offre et la transaction de ressources, compute, stockage, données, workflows, avec des garanties de sécurité et de souveraineté fortes. Les enregistrements sont signés par leur créateur, leur contenu est chiffré bout-en-bout, leur cycle de vie est sous contrôle du créateur via un TTL explicite, et leur consommation peut être attestée sans révéler le contenu. Le règlement monétaire n'a pas sa place ici : séparer la couche applicative de la couche financière est une nécessité architecturale, non un choix stylistique.
|
||
|
||
### Plan de Règlement Monétaire
|
||
|
||
Ce plan règle les compensations monétaires résultant de la consommation attestée de ressources. Ses exigences sont l'inverse du plan de découverte : finalité déterministe, cohérence forte, résistance à la censure par des validateurs adversariaux, smart contracts pour l'automatisation du paiement conditionnel. Un seul protocole ne peut satisfaire simultanément ces exigences et celles de la découverte, la fusion dégradrait inévitablement les garanties sur au moins une dimension. C'est la même raison pour laquelle le réseau téléphonique et le réseau bancaire sont des infrastructures distinctes, quand bien même 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 [18] 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 [2] é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 [23] 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 [22] 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.
|
||
|
||
### 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 :
|
||
|
||
**Ratio d'uptime (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 prévisibles mérite une évaluation haute. Cette dimension pénalise les pairs instables ou éphémères, un coût temporel qui freine les identités Sybil à durée de vie courte.
|
||
|
||
**Latence normalisée (15 %)** : mesure le temps de réponse aux requêtes, normalisé par la latence attendue selon le type de lien. Elle pénalise les pairs surchargés ou géographiquement trop distants, sans que cela constitue un signal de compromission.
|
||
|
||
**Précision des challenges (25 %)** : des challenges cryptographiques périodiques, écho de données DHT, vérification de contenu connu, permettent de vérifier que le pair héberge réellement les données qu'il annonce. C'est la dimension la plus résistante à la manipulation : elle requiert une réponse correcte à une question que l'adversaire ne peut anticiper. Elle constitue le vecteur de détection principal.
|
||
|
||
**Diversité réseau (15 %)** : mesure la diversité des sous-réseaux IP des pairs que ce nœud connaît. Elle favorise les pairs bien connectés à des régions réseau variées et pénalise implicitement les clusters de nœuds contrôlés par un même acteur.
|
||
|
||
**Taux de remplissage inverse (10 %)** : dans un marché de ressources, un pair offrant des capacités très chargées est moins utile qu'un pair disponible. Cette dimension oriente naturellement les nouveaux clients vers les pairs les moins sollicités, équilibrant la charge du réseau sans coordination centrale.
|
||
|
||
**Cohérence des témoins (10 %)** : les observations d'un pair par des témoins tiers (autres pairs qui l'ont récemment contacté) sont comparées aux observations directes. Une incohérence forte signale une possible compromission localisée ou une collusion.
|
||
|
||
**Fiabilité DHT (5 %)** : mesure la probabilité que les enregistrements confiés à ce pair soient restitués correctement. Elle détecte les pairs qui acceptent des enregistrements sans les stocker (comportement parasite) ou qui les altèrent.
|
||
|
||
**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 SWIM, Membership Épidémique avec Réfutation
|
||
|
||
Les événements d'appartenance (arrivée, départ, changement d'état) sont propagés par le protocole SWIM [9] (Scalable Weakly-consistent Infection-style process group Membership). Chaque événement est typé alive / suspect / dead et porte un numéro d'incarnation : un pair peut réfuter une suspicion en incrémentant son incarnation, ce qui neutralise les faux signaux de mort propagés à son encontre. La propagation est bornée par un compteur de sauts (HopsLeft décrémenté à chaque retransmission) qui empêche une campagne de désinformation de se propager au-delà d'un voisinage local.
|
||
|
||
Ces événements sont piggybacked sur les heartbeats existants, aucun canal dédié, aucun message supplémentaire. La déduplication repose sur la paire (PeerID, incarnation) : une incarnation plus haute ou un état de priorité supérieure (dead > suspect > alive) gagne. Ce mécanisme garantit une convergence en O(log n) étapes avec haute probabilité, sans coordination centrale, tout en résistant aux faux positifs de détection de panne inhérents aux contextes asynchrones (résultat FLP).
|
||
|
||
Pour les environnements hostiles, la diffusion des événements peut être restreinte aux paires de pairs partageant une clé de consortium, empêchant la fuite d'informations topologiques vers des observateurs extérieurs.
|
||
|
||
### 3.9 Cache DTN, Livraison Garantie en Connectivité Intermittente
|
||
|
||
L'adaptation DTN de la couche de données repose sur un cache de messages outbound à deux niveaux selon la criticité de la mutation.
|
||
|
||
**Niveau critique** couvre les mutations de ressources (CREATE / UPDATE / DELETE) : le message est retranté indéfiniment jusqu'à livraison confirmée. La persistance est chiffrée sur disque (AES-256-GCM, clé dérivée de façon déterministe de l'identité Ed25519 du nœud via HKDF) pour survivre aux redémarrages. La déduplication opère sur la clé `(peer_id, resource_id)` avec des règles de cycle de vie : DELETE est terminal (tout nouveau CREATE ou UPDATE pour le même couple est ignoré), UPDATE ne peut pas être suivi d'un CREATE (la ressource existe déjà côté pair). Ces règles garantissent que l'état final livré est cohérent quelle que soit la durée de l'interruption.
|
||
|
||
**Niveau modéré** couvre les confirmations, planners, et configurations : budget de trois essais puis abandon. Ces messages ne sont pas persistés sur disque, leur budget de retry est trop court pour qu'une restauration après redémarrage soit pertinente.
|
||
|
||
Lorsque la destination est un nœud Nano, tous les protocoles passent en niveau critique indépendamment de leur classification par défaut, un satellite peut être absent longtemps et aucune mutation ne doit être perdue.
|
||
|
||
**Mécanisme de réveil (PendingContact)** : plutôt qu'une boucle de retry aveugle, chaque nœud inclut dans son heartbeat la liste des peer IDs pour lesquels il a des entrées critiques en attente (`PendingContact`). Les indexeurs maintiennent un index inversé `peerID → [pairs qui l'attendent]`. Quand un pair reconnecte, il interroge cet index (`PendingCallers`) et initie le contact vers chaque pair en attente, déclenchant un flush immédiat du cache. Le signal s'éteint naturellement à la livraison, aucun timer additionnel, aucun protocole de callback dédié, redondance gratuite via les multiples indexeurs.
|
||
|
||
### 3.10 Hiérarchie Nano/Maître
|
||
|
||
Les nœuds à disponibilité très intermittente, typiquement des satellites ou des capteurs embarqués avec de courtes fenêtres de contact, peuvent être associés à un nœud maître présumé plus stable (station sol, concentrateur). Cette relation est un primitif de gouvernance et de délégation formellement encodé dans le peer record de chaque pair.
|
||
|
||
**Invariants fondamentaux :**
|
||
- Un nano n'est jamais un partenaire direct : toute relation de partenariat passe par son maître. Un tiers ne négocie pas avec le nano, il négocie avec son maître.
|
||
- Le maître est l'autorité du catalogue de ses nanos : il tient l'état à jour et propage les mutations dans les deux sens. Toute mutation (CREATE/UPDATE/DELETE) émise vers un nano par un émetteur qui n'est pas son maître enregistré est rejetée.
|
||
- Un maître envoie à un nano uniquement les ressources dont ce nano est propriétaire, pas l'intégralité du catalogue.
|
||
|
||
**Gestion des réservations en mode dégradé :**
|
||
|
||
*Cas nominal* : nano et maître joignables. La réservation est prise directement sur le nano, le maître est notifié ensuite (pas de DTN critique, le nano a déjà confirmé).
|
||
|
||
*Nano hors-ligne, maître joignable* : le maître prend la réservation en mode proxy avec `DestPeerID = nano.peer_id`, et la transmet au nano via le cache DTN critique à sa reconnexion.
|
||
|
||
*Split brain* : nano et maître déconnectés au moment où chacun prend une décision. À la reconnexion, **le maître a raison**, ses bookings priment sur ceux pris directement sur le nano pendant la déconnexion. Tout conflit (même resource_id, créneaux qui se chevauchent) est résolu en faveur du maître; le booking nano-only est annulé et le demandeur est notifié.
|
||
|
||
Cette règle de réconciliation déterministe est la seule qui garantisse la cohérence sans requérir de consensus distribué entre nano et maître au moment de la prise de décision, un consensus impossible précisément parce qu'ils sont déconnectés.
|
||
|
||
---
|
||
|
||
## 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 [14] ont formalisé ce paradigme; les constructions modernes basées sur des arguments non-interactifs à divulgation nulle (zk-SNARKs) [15] 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'a 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 |
|
||
| 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 |
|
||
| Penumbra | ✓✓ (ZK-SNARKs, pool aveugle) | ✓ (Tendermint ~6s) | △ (actions natives, pas CosmWasm) | ✓ (Cosmos zones) | ✓✓ | △ (testnet actif, mainnet récent) | Très prometteur ZK pur, contrats limités |
|
||
|
||
**Analyse détaillée des blockchains les plus pertinentes** :
|
||
|
||
**Hyperledger Fabric** [1] 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** [17] 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 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 [7] 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. La compatibilité Cosmos offre une interopérabilité avec un écosystème large.
|
||
|
||
**Zcash** [16] 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** [21] 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.
|
||
|
||
**Penumbra** est une zone Cosmos dont la confidentialité repose exclusivement sur des zk-SNARKs — aucune dépendance matérielle, contrairement aux solutions TEE. Son architecture centrale est un pool aveugle (shielded pool) : les actifs y sont déposés, les transactions s'y effectuent, et les retraits se font via des preuves cryptographiques qui ne révèlent ni les montants ni les participants. Le DEX intégré (batch swap) traite les échanges par lot à un prix uniforme sur chaque bloc, éliminant structurellement le MEV par front-running — propriété particulièrement pertinente pour un marché de ressources où les validateurs ne doivent pas pouvoir manipuler l'ordre des transactions. La connexion IBC est supportée et les transferts cross-chain transitent par des chemins chiffrés, préservant la confidentialité au-delà des frontières de la zone. La principale limitation de Penumbra est l'expressivité contractuelle : les "actions" natives (swap, delegation, vote) couvrent les cas usuels mais ne disposent pas d'un moteur de smart contracts générique comparable à CosmWasm. Pour des règlements de ressources avec logique conditionnelle complexe, cette limite est contraignante. Penumbra constitue la cible de migration naturelle depuis Secret Network dès que la maturité de son écosystème le permettra : même famille Cosmos, même interopérabilité IBC, confidentialité sans dépendance SGX.
|
||
|
||
### 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 confidentiel** : Secret Network pour les transactions entre acteurs de consortiums distincts, via des smart contracts CosmWasm confidentiels exécutés dans des enclaves TEE. Les attestations de consommation de ressources sont soumises on-chain, permettant de prouver la bonne exécution sans révéler le contenu des calculs. La dépendance SGX est assumée comme compromis pragmatique à court terme; Penumbra constitue la migration naturelle à moyen terme, apportant la même confidentialité sans dépendance matérielle via zk-SNARKs, dans le même écosystème Cosmos et avec la même interopérabilité IBC. Les contrats de règlement doivent être conçus comme une implémentation interchangeable d'une interface pour faciliter cette migration.
|
||
|
||
**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)
|
||
|
||
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) est la réponse la plus simple : accepter la clé lors du premier contact, avertir en cas de changement ultérieur. C'est pragmatique, mais la vulnérabilité à l'interception de ce premier échange est réelle. Les identifiants décentralisés (DID, spécification W3C [26]) offrent une alternative plus robuste : 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 PeerID libp2p (dérivés directement de la clé publique) constituent la forme la plus primitive de cette auto-certification.
|
||
|
||
Le risque résiduel est propre au contexte hostile : ancrer une identité DID dans une blockchain publique révèle son existence à tout observateur. Pour les environnements qui l'exigent, des identités éphémères rotatoires avec mécanismes de reconnaissance hors-bande constituent une alternative, au prix d'une complexité opérationnelle significativement plus élevée.
|
||
|
||
### Verrou 2, Bootstrap Trustless
|
||
|
||
Le premier contact avec le réseau suppose la connaissance d'au moins un pair de confiance. Ces seeds constituent une ancre de confiance qui ne peut être supprimée, seulement diversifiée et distribuée pour réduire le risque de compromission partielle. La proposition retient trois niveaux : seeds codés en dur géographiquement et organisationnellement diversifiés (analogie directe avec les directory authorities de Tor), DHT locale persistante pour les reconnexions ultérieures, et canal hors-bande sécurisé pour les déploiements à haute sécurité.
|
||
|
||
La limite est structurelle : aucun système sans seeds hardcodés ou sans canal hors-bande de confiance ne peut bootstrapper de manière véritablement trustless. L'ancre de confiance minimale est irréductible, ce qu'on peut faire est la rendre aussi résistante que possible à une compromission partielle.
|
||
|
||
### Verrou 3, Résistance Sybil sans Coût Cryptoéconomique
|
||
|
||
Douceur [10] 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, aucune solution unique n'est complète. La clé pré-partagée (PSK) organisationnelle est efficace dans les réseaux fermés mais requiert une coordination hors-bande pour chaque nouvel entrant. Le scoring comportemental multidimensionnel constitue une défense secondaire solide mais peut être contourné par un adversaire patient qui simule durablement un comportement exemplaire. Pour les réseaux ouverts, un dépôt cryptoéconomique (stake on-chain) est la seule barrière structurellement robuste, elle rend prohibitivement coûteuse la multiplication d'identités.
|
||
|
||
En pratique, la combinaison PSK + scoring suffit pour les réseaux de consortium. La barrière cryptoéconomique est réservée aux configurations ouvertes où des adversaires bien financés disposent du temps nécessaire pour bâtir une réputation factice.
|
||
|
||
### Verrou 4, Cohérence sans Consensus Fort (CAP)
|
||
|
||
Le théorème CAP [4][13] impose un choix entre cohérence et disponibilité lors d'un partitionnement. Choisir le profil CP pour la couche de découverte la rendrait indisponible lors des partitions DTN fréquentes, inacceptable opérationnellement. La proposition assume ce choix explicitement : profil AP pour la découverte (cohérence éventuelle, disponibilité prioritaire), profil 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 vecteurs d'horloge selon la criticité des enregistrements.
|
||
|
||
Ce qui ne disparaît pas pour autant : 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. C'est un risque connu et accepté, atténué par la durée typiquement courte de ces fenêtres dans les scénarios orbitaux prévisibles.
|
||
|
||
### Verrou 5, Détection de Panne sans Oracle (FLP)
|
||
|
||
Fischer, Lynch et Paterson [12] ont démontré qu'en présence d'asynchronisme, aucun algorithme déterministe ne peut distinguer un pair défaillant d'un pair simplement lent. Toute détection de panne est donc probabiliste par nature. Le protocole SWIM adresse ce problème de manière adaptée aux réseaux DTN : plutôt qu'un timeout binaire, il introduit une période de suspicion pendant laquelle un pair suspecté n'est pas immédiatement exclu mais marqué comme tel, la confirmation de la panne requérant la convergence de plusieurs observations indépendantes. Cette approche réduit significativement les faux positifs, particulièrement fréquents dans les environnements à haute latence.
|
||
|
||
Dans les réseaux DTN à très haute latence, les délais de confirmation peuvent atteindre plusieurs cycles orbitaux, pendant lesquels un pair défaillant ou malveillant reste présent dans les tables de voisinage. C'est la contrepartie inévitable du choix AP : une table avec quelques entrées stale est préférable à l'absence de table.
|
||
|
||
### Verrou 6, Confidentialité des Transactions sur Chaîne Publique
|
||
|
||
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 par analyse de clustering. Trois approches couvrent ce problème, chacune avec un périmètre différent.
|
||
|
||
Les ZK-SNARKs masquent cryptographiquement montants et adresses sans dépendance matérielle, la solution la plus pure, mais les constructions pour smart contracts complexes restent en cours de maturation. Les TEE (Intel SGX, ARM TrustZone) permettent une exécution confidentielle des smart contracts là où même les validateurs ne voient pas les données, mature dans l'écosystème Cosmos via Secret Network, mais soumis à des vulnérabilités de canal latéral documentées. Les blockchains permissionnées avec canaux privés offrent une confidentialité intra-consortium robuste, au prix d'une confiance requise dans les opérateurs du réseau. Ces trois approches ne sont pas exclusives et peuvent couvrir des périmètres complémentaires.
|
||
|
||
### Verrou 7, DTN et Transactions Intermittentes
|
||
|
||
Les blockchains classiques supposent une connectivité continue entre validateurs. Dans un réseau DTN, un validateur peut être absent plusieurs heures sans être défaillant, bloquant le quorum et donc le traitement des transactions pendant toute la durée de son absence. Les state channels offrent une réponse élégante : 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. Cette approche tolère des périodes de déconnexion arbitrairement longues mais requiert une connexion initiale pour l'engagement. La signature différée est une alternative plus simple : les transactions sont signées localement avec un timestamp, accumulées pendant la période hors-ligne, soumises en batch à la prochaine fenêtre de connexion, le smart contract vérifiant la validité temporelle et l'unicité des nonces.
|
||
|
||
Les optimistic rollups introduisent une fenêtre de contestation de plusieurs heures, ce qui est compatible DTN pour la latence mais techniquement moins adapté aux partitions prolongées que les state channels. Les deux approches peuvent coexister selon la criticité de la transaction.
|
||
|
||
### Verrou 8, Oracle et Preuve de Consommation Réelle
|
||
|
||
Szabo [25] a posé le problème fondamental : un smart contract de règlement doit vérifier qu'un calcul s'est réellement exécuté, que des données ont réellement été livrées, mais il opère dans un environnement blockchain isolé du monde physique. Trois approches permettent d'y répondre.
|
||
|
||
Les attestations TEE génèrent une preuve cryptographique signée par le microprocesseur lui-même, certifiant que le code spécifié s'est exécuté dans un environnement sécurisé (Intel SGX, ARM TrustZone). Les ZK-proofs d'exécution prouvent 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 permettent cette approche pour des programmes arbitraires, au prix d'un coût de génération encore élevé pour les programmes complexes. Le challenge-response interactif repose sur un échantillonnage aléatoire de résultats vérifiables que le fournisseur ne peut produire qu'en ayant réellement exécuté le calcul.
|
||
|
||
Dans la pratique, TEE et challenge-response sont les approches les plus immédiatement déployables. Les ZK-proofs d'exécution générique représentent la direction de long terme, leur coût de génération décroît à chaque génération de circuits.
|
||
|
||
---
|
||
|
||
## 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. 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
|
||
|
||
**[1] [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.
|
||
|
||
**[2] [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.
|
||
|
||
**[3] [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.
|
||
|
||
**[4] [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.
|
||
|
||
**[5] [Buchman, 2016]** Buchman, E. (2016). *Tendermint: Byzantine Fault Tolerance in the Age of Blockchains*. M.Sc. Thesis, University of Guelph.
|
||
|
||
**[6] [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.
|
||
|
||
**[7] [Costan & Devadas, 2016]** Costan, V., & Devadas, S. (2016). Intel SGX Explained. *IACR Cryptology ePrint Archive*, Report 2016/086.
|
||
|
||
**[8] [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.
|
||
|
||
**[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 the 2002 International Conference on Dependable Systems and Networks (DSN)*, pp. 303–312.
|
||
|
||
**[10] [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.
|
||
|
||
**[11] [Fall, 2003]** Fall, K. (2003). A delay-tolerant network architecture for challenged internets. In *Proceedings of SIGCOMM 2003*, pp. 27–34.
|
||
|
||
**[12] [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.
|
||
|
||
**[13] [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] [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] [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.
|
||
|
||
**[16] [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
|
||
|
||
**[17] [Kwon & Buchman, 2016]** Kwon, J., & Buchman, E. (2016). *Cosmos: A Network of Distributed Ledgers*. Whitepaper. https://v1.cosmos.network/resources/whitepaper
|
||
|
||
**[18] [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.
|
||
|
||
**[19] [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.
|
||
|
||
**[20] [Nakamoto, 2008]** Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System. https://bitcoin.org/bitcoin.pdf
|
||
|
||
**[21] [Oasis Labs, 2020]** Oasis Network (2020). *Oasis Network Primer*. Oasis Labs. https://oasisprotocol.org/primer
|
||
|
||
**[22] [Perrin, 2018]** Perrin, T. (2018). *The Noise Protocol Framework*. https://noiseprotocol.org/noise.pdf
|
||
|
||
**[23] [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.
|
||
|
||
**[24] [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.
|
||
|
||
**[25] [Szabo, 1997]** Szabo, N. (1997). Formalizing and securing relationships on public networks. *First Monday*, 2(9).
|
||
|
||
**[26] [W3C, 2022]** W3C (2022). *Decentralized Identifiers (DIDs) v1.0*. W3C Recommendation. https://www.w3.org/TR/did-core/
|
||
|
||
**[27] [Wood, 2014]** Wood, G. (2014). *Ethereum: A Secure Decentralised Generalised Transaction Ledger*. Ethereum Yellow Paper. https://ethereum.github.io/yellowpaper/paper.pdf
|
||
|
||
**[28] [Wood, 2016]** Wood, G. (2016). *Polkadot: Vision for a Heterogeneous Multi-Chain Framework*. Whitepaper. https://polkadot.network/PolkaDotPaper.pdf
|